ELC/LFCS2009: A tale of two panels [LWN.net]

ELC/LFCS2009: A tale of two panels

Posted Apr 15, 2009 19:16 UTC (Wed) by fuhchee (subscriber, #40059)
Parent article: ELC/LFCS2009: A tale of two panels

> Morton responded that for device drivers or supporting new architectures,
> the path is easier, but that the two examples Rostedt gave [systemtap
> and utrace] touch core kernel code.

This was mistaken. utrace does not touch core code, but only the hook
points already integrated in tracehook.h. Being a well-behaved user
of the module APIs, systemtap cannot possibly touch core kernel code
either.

> Morton likened the utrace battle to an "incestuous family struggle", but
> noted that the code needed improvement before it could go in.

This is probably mistaken, since there have been no technical critiques
of the recently submitted utrace code ... at all.

> One of the reasons that utrace didn't make it into the kernel was a
> lack of an in-kernel user of the code, Rostedt noted.

This is mistaken, since one proposed in-kernel user was posted right
alongside utrace (the ftrace engine), and another one was hacked together
within days (seccomp replacement). So there were already *two* that
fulfill some basic testing coverage.

We are working on two more utrace clients, as discussed later
during the tracing sessions, so that should bring the potential
in-kernel user count up to four. We hope that will be sufficiently
greater than zero.

(Log in to post comments)

ELC/LFCS2009: A tale of two panels

Posted Apr 15, 2009 21:51 UTC (Wed) by jake (editor, #205) [Link]

> This was mistaken. utrace does not touch core code, but only the hook
> points already integrated in tracehook.h. Being a well-behaved user
> of the module APIs, systemtap cannot possibly touch core kernel code
> either.

I guess I am not sure if you are responding to the article or to Andrew here. I believe I captured what he said correctly, so if you disagree with it, I think you need to take it up with him.

> This is probably mistaken, since there have been no technical critiques
> of the recently submitted utrace code ... at all.

I think Andrew was looking at the whole history of utrace, not just the most recent submission. I believe there were technical critiques of earlier submissions, yes?

> This is mistaken, since one proposed in-kernel user was posted right
> alongside utrace (the ftrace engine),

yes, but as has been discussed elsewhere (http://lwn.net/Articles/325180/), the ftrace-utrace engine was not considered a "real" user by Andrew and others. I know you disagree.

jake

ELC/LFCS2009: A tale of two panels

Posted Apr 15, 2009 22:01 UTC (Wed) by fuhchee (subscriber, #40059) [Link]

> I guess I am not sure if you are responding to the article or to Andrew here.

Your summary was accurate; this is more for Andrew and affected listeners.

> [...] I believe there were technical critiques of earlier submissions, yes?

That's true, but it's old history that doesn't justify using the
present tense in casually dismissing the code.

ELC/LFCS2009: A tale of two panels

Posted Apr 15, 2009 22:36 UTC (Wed) by fuhchee (subscriber, #40059) [Link]

> Your summary was accurate

Actually, it might not have been. I seem to recall someone on the panel
describing utrace as changing code "all over the kernel", which would be
different (and more mistaken). I guess once the LF video gets released,
our memories can be checked.

(I wish this sort of pedantry were not necessary, but words from important
people carry weight, so they had better be correct.)

ELC/LFCS2009: A tale of two panels

Posted Apr 18, 2009 12:01 UTC (Sat) by ebiederm (subscriber, #35028) [Link]

tracehook.h was one of the early parts of utrace that got merged.

utrace was merged in -mm for a while and the results were bad enough that it got yanked at least once.

As for the utrace ftracer. utrace predates ftrace by several years and it certainly did not exist before it was merged.