On Sat, Jan 23, 2010 at 14:48, ty...@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
