[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2



On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche redhat com> wrote:

> Hi -
> 
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the 
> > > whole utrace machinery is just something that provides a _ton_ of 
> > > hooks to something entirely external: SystemTap mainly.
> > 
> > Roland's changelogs don't mention systemtap at all afacit.
> > That was, umm, major information lossage.
> 
> There have been many mixed messages from LKML on the topic - sometimes
> mentioning systemtap is forbidden, other times necessary.  Sorry about
> that.

heh.  We all love systemtap and want it to get better.

> There are several non-systemtap clients in existence or under
> development.  You've may have heard of the ptrace cleanup, a
> multi-client ptrace replacement, an on-the-fly core dumper, the ftrace
> widget, user-space probes.  All of these should have somewhat
> compelling non-systemtap uses, if that's an important criterion.

Well I dunno.  You guys are closer to this than I am, but I'd have thought
that systemtap is the main game here, and most/all of the above is just
fluff.

IOW, "this helps systemtap" is sufficient reason for merging a kernel
change.  For sufficiently large values of "help", and sufficiently small
values of "eww", of course.



I have strong memories of being traumatised by reading the uprobes code. 
What's the story on all of that nowadays?


> 
> > Actually it seems that the whole utrace-ftrace thing is a big
> > distraction and could/should just be omitted.  This is a systemtap
> > feature and should be viewed as such. [...]
> 
> utrace is a better way to perform user thread management than what is
> there now, and the utrace-ftrace widget shows how to *hook* thread
> events such as syscalls in a lighter weight / more managed way than
> the first one proposed.  (That's one reason we've been participating
> in the ftrace discussions.)  Of course it can be made to use the fine
> syscall pretty-printing code recently added.

eh.  Boring.  Let's fix systemtap?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]