[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y0m7ia3xqev.fsf@ton.toronto.redhat.com>
Date: Tue, 26 Aug 2008 20:17:12 -0400
From: fche@...hat.com (Frank Ch. Eigler)
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Roland McGrath <roland@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] utrace
Alexey Dobriyan <adobriyan@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists