lkml.org 
[lkml]   [2009]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2009-03-11 12:55    [W:0.025 / U:0.560 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site