> 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
> 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.