Re: linux-next: add utrace tree

[Kyle Moffett <kyle@moffetthome.net>]

On Sat, Jan 23, 2010 at 14:48,  <tytso@mit.edu> wrote:
> The fundamental issue which Ingo is trying to say (and which you
> apparently don't seem to be understanding) is that utrace doesn't
> export a syscall (which is an ABI that we are willing to promise will
> be stable), but rather a set of kernel API's (which we never promise
> to be stable),

The point that's being missed is that there is a chicken-and-egg
problem here.  The "chicken" is a replacement or extension to the
debugger interface that would make it possible for me to do things
like GDB a process while it's being strace'd or vice versa.  The "egg"
is the "utrace" bits, an unstable but somewhat arch-generic ABI that
abstracts out ptrace() to make it possible to stack both in-kernel and
userspace debuggers/tracers/etc and have multiple simultaneous users.

> and the fact that there will be out-of-tree programs
> that are going to be trying to depend on that interface (much like
> Systemtap does today when it creates kernel modules) is something that
> is considered on par with Nvidia trying to ship proprietary video
> drivers.

Ugh... perhaps we should derive a variation of Godwin's law for this:

"As an LKML discussion grows longer, the probability of an unfavorable
comparison involving nVidia or Microsoft approaches 1."


> If you want to try to slide utrace in, such that we're able to ignore
> the fact that there will be this external house that will be built on
> quicksand, pointing at how nice the external house will be isn't going
> to be helpful.  Nor is pointing at the ability that other people will
> be able to build other really nice houses on the aforementioned
> quicksand (i.e., out-of-tree kernel modules that depend on kernel
> API's).

Personally I don't give a flying **** about SystemTap; I'm interested
in things like the ability to stack gdb with strace, the RFC gdb-stub
posted a week ago, etc.  None of those abilities would be out-of-tree
modules at all, and therefore the "quicksand" analogy is specious.


> A simple "code cleanup" argument is not carrying the day (Look!  We
> can cleanup the ptree code!).  It's going to have to be a **really**
> cool in-tree kernel funtionality that provides a killer feature (in
> Linus's words), enough so that people are willing to overlook the fact
> that there's this monster external out-of-tree project that wants to
> be depend on API's that may not be stable, and which, even if the
> developers don't grump at us, users will grump at us when we change
> API's that we had never guaranteed will be stable, and then Systemtap
> breaks.

I would be willing to guess that something like 95% of the people
using SystemTap or other tools are doing so on Red Hat Enterprise
Linux or other enterprise supported platforms, and so when something
breaks they go whinge at Red Hat, etc.  If I recall correctly Red Hat
and many of the other vendors already heavily fiddle with kernel
patches they apply to provide some amount of binary module
compatibility.


> This is probably why Ingo invited you to think about ways of doing
> some kind of safe in-kernel bytecode approach.  That has the advantage
> of doing away with external kernel modules, with all of their many
> downsides: its dependency on unstable kernel API's, the fact that many
> financial customers have security policies that prohibit C compilers
> on production machines, the inherent security risk of allowing
> external random kernel modules to be delivered and loaded into a
> system, etc.

There are substantial non-SystemTap uses for utrace that would *not*
be satisfied by an "in-kernel bytecode approach", starting with
stacking debuggers and tracers.  Furthermore, let's say they did go
off and build the in-kernel bytecode interpreter.  I can pretty much
guarantee that people would say the hooks into the rest of the kernel
are too invasive and they should be abstracted out into an API.  *This
is that API!*

Cheers,
Kyle Moffett