Re: [Patch 01/11] Introducing generic hardware breakpoint handlerinterfaces

[K.Prasad]

On Fri, Mar 20, 2009 at 07:30:58PM +0100, Ingo Molnar wrote:
> 
> * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/