This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: documentation for user-space usage?
grant.b.edwards wrote:
> [...]
> Assuming utrace/uprobes gets ported to ARM, does such a trace events
> involve a context switch to kernel-mode and then back to user-mode?
Yes.
> [...] I'm using ARM9. Utrace support patches have apparently been
> rejected by the kernel maintainers, so I'd hae to maintain my own
> fork of the kernel as well as port uprobes. I think.
How close is your current kernel to fedora's?
>> [...] User-space probing and kernel-space probing are basically identical
>> from the point of view of the stap user.
>
> Is the timing impact of a user-space probe no different than that of a
> kernel-space probe?
It's very similar.
>> [...]
>> The theoretical fit is pretty good. If in practice you are blocked
>> by some missing unported layer, you could decide between helping
>> port, prototyping on x86 while someone else ports, and/or
>> investigating other logging-related tools/libraries.
>
> I wouldn't mind working on porting uprobes if I was confident that it
> would be accepted upstream. Since utrace support was apparently not
> accepted, I'm not too optimistic.
Another option is to go ahead and try to port uprobes, leave
ARM/utrace to us / fedora people. When/if the newer lkml-track
uprobes gets merged, the hypothetical ARM port could go into the main
kernel that way, bypassing the utrace kerfuffle. IOW, doing an ARM
port of the current systemtap-resident uprobes would not be a wasted
effort, if LKML gets its act together and merges the other one.
- FChE