Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64

From: David Gibson <dwg@au1.ibm.com>
To: "K.Prasad" <prasad@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org,
	Benjamin Herrenschmidt <benh@au1.ibm.com>,
	paulus@samba.org
Subject: Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64
Date: Wed, 13 May 2009 12:57:17 +1000	[thread overview]
Message-ID: <20090513025717.GN24338@yookeroo.seuss> (raw)
In-Reply-To: <20090512202545.GE6033@in.ibm.com>

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.

-- 
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