On Sat, Jan 23, 2010 at 14:48, <tytso@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
