lkml.org 
[lkml]   [2009]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch 01/11] Introducing generic hardware breakpoint handler interfaces
On Fri, Mar 20, 2009 at 07:30:58PM +0100, Ingo Molnar wrote:
>
> * Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > > + * Kernel breakpoints grow downwards, starting from HB_NUM
> > > + * 'hbkpt_kernel_pos' denotes lowest numbered breakpoint register occupied for
> > > + * kernel-space request
> > > + */
> > > +unsigned int hbkpt_kernel_pos;
> >
> > This doesn't make much sense. All you need to know is which
> > registers are in use; all others are available.
> >
> > For example, suppose the kernel allocated breakpoints 3, 2, and 1,
> > and then deallocated 2. Then bp 2 would be available for use,
> > even though 2 > 1.
>
> it's a high/low watermark mechanism. Yes, it's not an allocator that
> can allocate into a debug registrs 'hole', but it is a simple one
> that matches current hardware breakpoint usages and enables the
> kernel to utilize them as well - and keeps all the code simple.
>
> Ingo

I've explained the design here: http://lkml.org/lkml/2009/3/21/169 in a
and is slightly different from what you've explained above.

It involves shifting of kernel-space registers by one-level if a
kernel-register is uninstalled. We compact the kernel-space registers
since a)not to leave a 'hole' thereby wasting a register forever during
runtime b)kernel-space requests are not specific to a register number
and can be moved at will (unlike user-space requests).

Hope that the design is acceptable and the resultant code - simple.

Thanks,
K.Prasad



\
 
 \ /
  Last update: 2009-03-21 18:35    [W:0.086 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site