Messages in this thread | | | Date | Wed, 11 Mar 2009 12:53:00 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 06/11] Use virtual debug registers in process/thread handling code |
| |
* Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 10 Mar 2009, Ingo Molnar wrote: > > > * Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > Speaking of switch_to_thread_hw_breakpoint(), i dont like > > > > that function at all: > > > > > > > > - why does it have to do a list of debug registers? > > > > > > I'm not sure I understand the point of this question. Are you > > > asking why the hw_breakpoint structures are stored on a list? > > > Because there can be an arbitrarily large number of them. > > > > But that does not make much sense. There's just 4 hardware > > registers. There's no sane way to overcommit them hence we > > _should not_. > > The number of hardware registers will vary according to the > architecture. Our intention was to make the hardware > breakpoint interface architecture-neutral, as nearly as > possible. Hence we decided to let callers register arbitrary > numbers of breakpoints, and inform them when the breakpoints > actually got installed in or uninstalled from the debug > registers.
This may sound as handwaving, but the thing is, it's best to do these kinds of things gradually. Keep it clean, design for sane hardware first (and x86, as a rare exception i guess, is rather sane when it comes to hw debug features), add quirks on an as-needed basis.
That principle is _especially_ true when a feature with borderline utility is merged. We had to do that with KGDB: had to strip down a decade of cruft and it really helped.
> If you think this design decision is a bad one, we can discuss > it. But Roland should be involved, because it is in large > part his design.
Sure.
> > > > - why does it worry about IPIs arriving when context-switches on > > > > x86 are always done with interrupts disabled? > > > > > > The routine gets invoked at times other than during a > > > context switch. However you may be right that these times > > > are all mutually exclusive. If so then a good deal of > > > complication can be removed. > > > > Yes. > > After looking through it more carefully, I think you're right > -- if a kernel breakpoint change does occur while > switch_to_thread_hw_breakpoint() is running then the IPI will > arrive immediately afterward, so there's no need to check for > it explicitly. (When this was written I probably wasn't aware > that interrupts are disabled during context switches.) So all > the stuff involving "goto restart" can be removed.
Good - that certainly makes the code we execute during context-switch a lot more palatable.
Ingo
| |