[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090311115300.GH2282@elte.hu>
Date: Wed, 11 Mar 2009 12:53:00 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Alan Stern <stern@...land.harvard.edu>
Cc: prasad@...ux.vnet.ibm.com,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Roland McGrath <roland@...hat.com>
Subject: Re: [patch 06/11] Use virtual debug registers in process/thread
handling code
* Alan Stern <stern@...land.harvard.edu> wrote:
> On Tue, 10 Mar 2009, Ingo Molnar wrote:
>
> > * Alan Stern <stern@...land.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists