This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]