Re: [GIT PULL v6] hw-breakpoints: Rewrite on top of perf events v6

[Ingo Molnar]

* K.Prasad <prasad@xxxxxxxxxxxxxxxxxx> wrote:

> On Sun, Nov 08, 2009 at 04:28:54PM +0100, Frederic Weisbecker wrote:
> > Ingo,
> > 
> > Please pull the tracing/hw-breakpoints branch that can be found at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
> > 	tracing/hw-breakpoints
> >
> 
> Hi Frederic, Ingo,
> 		Here are a few concerns (roughly in decreasing order of
> priority) about the perf-events integrated hw-breakpoint feature.
> 
> - Freeze the breakpoint interfaces: Owing to the many 
> current/potential users of hw-breakpoint feature it is important to 
> provide a stable interface to the end-user. Changes underneath the 
> interface can be done in due course in a manner that does not affect 
> the end-user's behaviour or function signature. The present breakpoint 
> interface requires parameters that are best embedded in a structure 
> for extensibility.

Well we have PERF_TYPE_BREAKPOINT right now. I agree that it should be 
finalized in some sort of extensible ABI real soon - we dont want (and 
dont need to) add all features that might be possible in the future.

> - Proposed migration of register allocation logic to arch-specific 
> files from kernel/hw_breakpoint.c. This is best done early to help 
> easy porting of code to other architectures (we have an active 
> interest in bringing support for PPC64 and S390). If done later, it 
> will entail additional effort in porting for each architecture.

I think the general direction should be towards librarized common 
frameworks.

If an architecture wants to do something special it should either extend 
the core code, or, if it's too weird to be added to the core, override 
it via its own implementation.

> - Fix ptrace bugs that potentially alter the semantics of ptrace.

Is there a specific list of these bugs?

> - Bring either true system_wide support or atleast workaround the 
> side-effects of iterative per-cpu registration using single atomic 
> enablement of all per-cpu breakpoints. This can avoid stray exceptions 
> which would get delivered to the end-user even for failed breakpoint 
> requests.

That can certainly be done when users of such facilities emerge. Right 
now we have perf and ptrace as the two users - are they affected by 
these problems?

Thanks,

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