[RFC] Hardware Breakpoint interfaces implementation for PPC64

[David Gibson]

On Wed, May 13, 2009 at 12:57:17PM +1000, David Gibson wrote:
> On Wed, May 13, 2009 at 01:55:45AM +0530, K.Prasad wrote:
> > On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> [snip]
> > I do see that Book-E processors will have severe memory footprint
> > constraints (in embedded environment) and if the maintainers carry a
> > different perspective (than the one cited above), the relevant fields
> > can be migrated to a new structure whose pointer will be embedded in
> > task_struct. The generic code may have to carry some #ifdefs though.
> 
> I think moving the debug register info into a separate structure makes
> a fair bit of sense.  As well as reducing the memory footprint for
> systems with lots of debug regs, checking it the pointer is NULL
> provides a simple and generic way of determining if the process has
> touched the debug regs.
> 
> It seems to me that a kind of minimal requirement for a sensible
> generic debug interface is that if no processes actually ask to use
> the debug regs, then we should never touch them in the hardware.  This
> means that debugging hacks in the kernel can just use the debug regs
> directly and don't have to go through the interface to avoid having
> their stuff clobbered on context switch.

Uh, sorry, didn't fully read the earlier mail.  Ingo makes a good
point that detaching the structure complicates locking / lifetime
issues.  Leaving it in the thread_struct probably makes sense for now.

Although it raises other issues for when different CPUs in the same
architecture have different sets of debug registers (e.g. PPC server's
DABR/IABR set versus 44x's IAC/DAC/DBCR regs).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson