Messages in this thread | | | Date | Tue, 15 Mar 2011 12:02:45 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes |
| |
On Tue, 15 Mar 2011, Srikar Dronamraju wrote: > > > TODO: Documentation/trace/uprobetrace.txt > > > > without a reasonable documentation how to use that is a brilliant > > argument? > > We had a fairly decent documentation for uprobes and > uprobetracer. But that had to be changed with the change in > underlying design of uprobes infrastructure. Since uprobetrace is one > the user interface, I plan to document it soon. However it would be > great if we had inputs on how we should be designing the syscall.
Ok.
> > Or some sensible implementation ? > > Would syscall based perf probe implementation count as a sensible > implementation? My current plan was to code up the perf probe for
Yes.
> uprobes and then draft a proposal for how the syscall should look. > There are still some areas on how we should be allowing the > filter, and what restrictions we should place on the syscall > defined handler. I would like to hear from you and others on your > ideas for the same. If you have ideas on doing it other than using a > syscall then please do let me know about the same.
I don't think that anything else than a proper syscall interface is going to work out.
> I know that getting the user interface right is very important. > However I think it kind of depends on what the infrastructure can > provide too. So if we can decide on the kernel ABI and the > underlying design (i.e can we use replace_page() based background page > replacement, Are there issues with the Xol slot based mechanism that > we are using, etc), we can work towards providing a stable User ABI that > even normal users can use. For now I am concentrating on getting the > underlying infrastructure correct.
Fair enough. I'll go through the existing patchset and comment there.
Thanks,
tglx
| |