Messages in this thread | | | Subject | Re: [PATCH 0/2] utrace | From | (Frank Ch. Eigler) | Date | Tue, 26 Aug 2008 20:17:12 -0400 |
| |
Alexey Dobriyan <adobriyan@gmail.com> writes:
> [...] And some internal details still horrible and overdesigned > just like at the very beginning.
Please point out specific areas, and I'm sure there will be a reasonable explanation why they turned out this way.
As for whether "struct utrace" should be a member of vs. pointed-to from task_struct, it may come down to the perceived need to avoid penalizing every thread with a hundred-odd bytes extra, whether or not they are being utrace-controlled.
> [...] Linked list of attached tracers? I don't know. One the bad > side, where are those nice tracing modules? Where are they?
Among others, utrace is an enablement layer for systemtap user-space probing, through another subsequent part that implements a kprobes-like API for user-space tasks. All this code now exists in at least prototype form, so if you need to see the bigger picture, look that way. Other users are anticipated, but first we need to get past the chicken-and-egg.
> This all similar to systemtap/markers story. Big changes under > promises that now, now somebody will use our thing.
In what way do you think those promises are unfulfilled? Systemtap has interfaced to markers since the beginning, and there are a bunch of markers in the tree.
- FChE
| |