From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Fri, 22 Jan 2010 01:30:24 UTC
Message-ID: <fa.e/4fdEcFZqlNpmLnWUHWtnJ7I+A@ifi.uio.no>

On Thu, 21 Jan 2010, Andrew Morton wrote:
>
> ptrace is a nasty, complex part of the kernel which has a long history
> of problems, but it's all been pretty quiet in there for the the past few
> years.

More importantly, we're not ever going to get rid of it.

Quite frankly, judging my all past history we have ever seen in kernel
interfaces, new an non-portable interfaces simply are never used. The
whole question whether they are nicer or not is entirely immaterial.

I'm personally very dubious that there are any merits to utrace that
outweigh the very clear disadvantages: just another layer that adds a new
level of abstraction to the only interface that people actually _use_,
namely ptrace.

But I haven't followed utrace. I doubt _anybody_ has, except for the
utrace people themselves.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Fri, 22 Jan 2010 22:00:16 UTC
Message-ID: <fa.nLvlNJFf+S39iQE0JxYo+CB+zcE@ifi.uio.no>

On Fri, 22 Jan 2010, Frank Ch. Eigler wrote:
>
> Finally, I don't know how to address the logic of "if a feature
> requires utrace, that's a bad argument for utrace" and at the same
> time "you need to show a killer app for utrace".  What could possibly
> satisfy both of those constraints?  Please advise.

The point is, the feature needs to be a killer feature. And I have yet to
hear _any_ such killer feature, especially from a kernel maintenance
standpoint.

The "better ptrace than ptrace" is irrelevant. Sure, we all know ptrace
isn't a wonderful feature. But it's there, and a debugger is going to have
support for it anyway, so what's the _advantage_ of a "better ptrace
interface"? There is absolutely _zero_ advantage, there's just "yet
another interface". We can't get rid of the old one _anyway_.

And the seccomp replacement just sounds horrible. Using some tracing
interface to implement security models sounds like the worst idea ever.

And like it or not, over the last almost-decade, _not_ having to have to
work with system tap has been a feature, not a problem, for the kernel
community.

So what's the killer feature?

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Sat, 23 Jan 2010 00:11:57 UTC
Message-ID: <fa.E9UfzWX+JM4fZ/ScvxV7f9Cn2w4@ifi.uio.no>

On Fri, 22 Jan 2010, Frank Ch. Eigler wrote:
>
> The point is that the intermediate api will allow (and, as the part
> you clipped out about utrace-gdbstub said, *already has allowed*)
> alternative plausible interfaces that coexist just fine.

And my point is that multiple interfaces are BAD.

There is one interface we _have_ to have: the traditional ptrace one. That
one we can't get away from.

"Multiple interfaces" on its own is just confusion with no upside.

You need a _reason_ to have other interfaces. They need to have that
killer feature. Just being "different" is not a feature at all.

> So all this is about *naming* utrace?  It was never built "for
> tracing", but for (efficient/multiplexed) *control*.  That wasn't even
> its original name -- one of your lieutenants asked roland to change it
> to utrace.

No. It's not about naming. It's about the downside of having amorphous
interfaces that apparently don't even have rules, and are then used to
implement random crap.

Yes, the SNL skit about "It's a dessert topping _and_ a floor wax" was
funny, but it was funny exactly because it was crazy.

The fact that you can do crazy things is not a good thing. You need to
find the "goodness" somewhere else, and that's what I'm trying to tell
you.

You just seem to have trouble listening.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Sat, 23 Jan 2010 00:23:52 UTC
Message-ID: <fa.NKEj7SN8ojifRfS8tP48eVjULP0@ifi.uio.no>

On Fri, 22 Jan 2010, Linus Torvalds wrote:
>
> No. It's not about naming. It's about the downside of having amorphous
> interfaces that apparently don't even have rules, and are then used to
> implement random crap.
>
> Yes, the SNL skit about "It's a dessert topping _and_ a floor wax" was
> funny, but it was funny exactly because it was crazy.

Put yet another way: I'd _much_ rather have two totally separate pieces
that don't depend on each other, and do different things.

So to take a very practical example: I'd much rather have 'seccomp' and
'ptrace' that have _nothing_ what-so-ever to do with each other, than have
some intermediate layer that then needs to make both of those happy, and
that both have to interact with.

There are cases where we really _want_ to have common code. We want to
have a common VFS interface because we want to show _one_ interface to
user space across a gazillion different filesystems. We want to have a
common driver layer (as far as possible) because - again - we expose a
metric shitload of drivers, and we want to have one unified interface to
them.

But going the other way: trying to share code when the interfaces are
fundamentally _different_ is generally not at all such a great idea. It
ends up tying two conceptually totally separate things together, and
suddenly people who work on feature X aneed to modify infrastructure that
affects feature Y, and it turns ou that details A, B and C are all totally
different for the two features and the middle layer has two conflicting
things it needs to work with.

This is why when somebody brought up "you could do a seccomp-like thing on
top of utrace" that my reaction was and is just totally negative. It shows
all the wrong kinds of tying things together.

			Linus

From: tytso@mit.edu
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Sat, 23 Jan 2010 19:49:23 UTC
Message-ID: <fa.4BFigbD7jYoem3y3prnGkl7ZsZI@ifi.uio.no>

On Sat, Jan 23, 2010 at 06:47:29AM -0500, Frank Ch. Eigler wrote:
> > What utrace does is that it provides an opaque set of APIs for
> > unspecified and out of tree _kernel_ modules (such as systemtap). It
> > doesnt support any 'application' per se. It basically removes the
> > kernel's freedom at shaping its own interaction with debug
> > application.
>
> This claim is hard to take any more seriously than emoting that the
> blockio layer is "opaque" because device drivers "remove freedom" for
> the kernel to "shape its interaction" with hardware.  If you have any
> *real evidence* about how any present user of utrace misuses that
> capability, or interferes with the "kernel's freedom", show us please.

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

(OK, maybe not *quite* as evil as Nvidia because at least SystemTap is
open source, but the bottom line is that enabling out-of-tree modules
isn't considered a good thing, and if we know in advance that there
are out-of-tree modules, there is a strong tendency to want to nip
those in the bud.)

The reason why I avoid Nvidia hardware like the plague is because I
work on bleeding-edge kernels, and even though companies like Nvidia
and Broadcom try very hard to keep up with released upstream kernels,
#1, there is always the concern of what happens if they decide to
change that policy, and #2, invariably something will break during the
-rc1 or -rc2 stage, and then my laptop is useless for running bleeding
edge kernels.  It's one of the reasons why many kernel developers gave
up on SystemTap, because it's not something that can be trusted to be
there, and the fault is not on our changing the API's, it's on
SystemTap depending on API's that were never guaranteed to be stable
in the first place.

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

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.

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.

       	       	     	       	   	  - Ted

From: tytso@mit.edu
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 07:51:14 UTC
Message-ID: <fa.3SLrPsk/Lw2bv0AhdzQ3V+pT83I@ifi.uio.no>

On Sun, Jan 24, 2010 at 08:42:13PM -0500, Kyle Moffett wrote:
>
> 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.

Great.  So what should be reviewed is utrace *plus* these other
userland interfaces, which may get critiqued and improved, and utrace
patches can be reviewed in light of these new features.  But be
warned.... if it turns out that only 30% of utrace is only needed to
support gdb stacking with strace, etc., the other 70% will likely get
ejected and the utrace patches streamlined to support these in-tree
users.  But since you don't give a flying **** about SystemTap,
presumably you won't mind, right?


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

Sure, but as out-of-tree modules, the best they can expect is that
most kernel developers will pretend that they don't exist.  Which is
OK, when I tried using SystemTap most of the concerns which I
expressed as being critical for kernel developers were largely ignored
(as near as I could tell) because the target market was RHEL corporate
customers, and they prioritized their resourcing accordingly --- so
they shouldn't mind if kernel developers return the favor.

But that means that we should only merge those portions of utrace that
are needed for these alleged "killer new features", and only if these
new features are cool enough that they justify the new code on their
own merits.   At least, IMNSHO.

						- Ted

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Sun, 24 Jan 2010 05:06:17 UTC
Message-ID: <fa.3FypVK5ZFTDJRUi3/RO3PoFytiU@ifi.uio.no>

On Sat, 23 Jan 2010, Kyle Moffett wrote:
>
> Now how do we get from here to a moderately portable API for
> interrogating, controlling, and intercepting process state?

Umm? ptrace?

It's not _pretty_, but it's a hell of a lot more portable than utrace is
ever going to be. Yes, the details differ between OS's (and between
architectures), but let's face it, things like register state probing is
_never_ going to be portable across different architectures simply because
the register state isn't the same.

> The killer app for this will be the ability to delete thousands of
> lines of code from GDB, strace, and all the various other tools that
> have to painfully work around the major interface gotchas of ptrace(),
> while at the same time making their handling of complex processes much
> more robust.

No. There is absolutely _no_ reason to believe that gdb et al would ever
delete the ptrace interfaces anyway.

That really is my point. Adding a new interface, when an old and crufty
(but working) interface is inevitably going to be around anyway - and is
inevitably always going to have portability issues - is STUPID.

Let's take strace, for example.

Yes, ptrace() is crufty, but have you actually looked at strace source
code? The problem isn't really a crufty interface to read registers etc,
the bigger problem for strace is that different architectures and OS's
have different system call argument rules, different ways to read/write
system call numbers yadda yadda yadda.

Take a look at strace sources some day. Moving away from ptrace on Linux
(even if you decided that you don't care about old versions of the kernel
that don't know anything else) would simplify ABSOLUTELY NOTHING.

Really. Quiet the reverse, I suspect. The Solaris and FreeBSD support uses
ptrace too, afaik, so you' just be confusing the issue.

And the fact is, strace would still end up supporting ptrace anyway, just
so that you could run it on old kernels.

So the whole "making a new utrace interface would simplify things" is
simply a total lie. The fact that ptrace is a bit of an odd interface IN
NO WAY means that any other interface would end up being appreciably
simpler.

It would just result in _more_ code in strace, and more confusion.

		Linus

From: tytso@mit.edu
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Sun, 24 Jan 2010 10:25:50 UTC
Message-ID: <fa.ff+wJaz3RAfpQAWznmZZ058Z+Vc@ifi.uio.no>

On Sat, Jan 23, 2010 at 09:04:56PM -0800, Linus Torvalds wrote:
> > The killer app for this will be the ability to delete thousands of
> > lines of code from GDB, strace, and all the various other tools that
> > have to painfully work around the major interface gotchas of ptrace(),
> > while at the same time making their handling of complex processes much
> > more robust.
>
> No. There is absolutely _no_ reason to believe that gdb et al would ever
> delete the ptrace interfaces anyway.

More to the point, gdb *couldn't* use utrace, because utrace only
exports a kernel API; not a syscall interface.  And if the Red Hat
Toolchain folks are thinking about encouraging gdb to start creating
out-of-tree kernel modules, so that (a) gdb requires root privs, and
(b) gdb is as (un)stable as SystemTap with respect to development
kernels by making it dependent on internal kernel API's, the Red Hat
Toolchain group needs to be smacked upside the head...

	  	      	    	    	   - Ted

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Fri, 22 Jan 2010 01:34:24 UTC
Message-ID: <fa.F4S6VE0cUmUVzaPT+bdHuB3tjtc@ifi.uio.no>

On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
>
> To the extent the discussion is colored by the new features enabled
> from this refactoring, well, there is Oleg's list which may or may not
> have mentioned enabling systemtap's user-space probing.

Let's face it, system tap isn't going to be merged, so why even bring it
up? Every kernel developer I have _ever_ seen agrees that all the new
tracing is a million times superior. I'm sure there are system tap people
who disagree, but quite frankly, I don't see it being merged considering
how little the system tap people ever did for the kernel.

So if things like system tap and "security models that go behind the
kernel by tying into utrace" are the reasons for utrace, color me utterly
uninterested. In fact, color me actively hostile. I think that's the worst
possible situation that we'd ever be in as kernel people (namely exactly
the "do things in kernel space by hiding behind utrace without having
kernel people involved")

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Fri, 22 Jan 2010 02:37:02 UTC
Message-ID: <fa.NEotWCWfPzFCtbM035epc/BxjGs@ifi.uio.no>

On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
>
> Less passionate analysis would identify a long history of contribution
> by the the greater affiliated team, including via merged code and by
> and passing on requirements and experiences.

The reason I'm so passionate is that I dislike the turn the discussion was
taking, as if "utrace" was somehow _good_ because it allowed various other
interfaces to hide behind it. And I'm not at all convinced that is true.

And I really didn't want to single out system tap, I very much feel the
same way about some seccomp-replacement "security model that the kernel
doesn't even need to know about" thing.

So don't take the systemtap part to be the important part, it's the bigger
issue of "I'd much rather have explicit interfaces than have generic hooks
that people can then use in any random way".

I realize that my argument is very anti-thetical to the normal CS teaching
of "general-purpose is good". I often feel that very specific code with
very clearly defined (and limited) applicability is a good thing - I'd
rather have just a very specific ptrace layer that does nothing but
ptrace, than a "generic plugin layer that can be layered under ptrace and
other things".

In one case, you know exactly what the users are, and what the semantics
are going to be. In the other, you don't.

So I really want to see a very big and immediate upside from utrace.
Because to me, the "it's a generic layer with any application you want to
throw at it" is a _downside_.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 16:54:32 UTC
Message-ID: <fa.IaJhy67Qgp8AiSdYyi8BNMCpg/I@ifi.uio.no>

On Sun, 24 Jan 2010, Kyle Moffett wrote:
>
> 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.

Quite frankly, as far as I'm concerned, I'd be a whole lot more interested
in utrace if it's _only_ stated (and implied) goal was to do exactly this.

The thing I object to is the whole "dessert topping _and_ floor wax"
thing, with kernel interfaces for random other users.

If somebody extended ptrace in good ways, that's a totally different
thing. But I think utrace has been over-designed, possibly as a result of
others coming in and saying "hey, I'd like to use that too for xyz".

"Do one thing, and do it well". I'd not mind somebody improving ptrace
(including extending its semantics - I do agree that the whole SIGSTOP
thing makes it hard to have multiple debuggers).

That said, I also suspect that people should still look seriously at
simply just improving ptrace. For example, I suspect that the biggest
problem with ptrace is really just the signalling, and that creating a new
extension for JUST THAT, and then having a model where you can choose - at
PTRACE_ATTACH time - how to wait for events would be a good thing.

But as long as it is "I want to solve all problems", I'm not very
impressed.

Maybe somebody would be interested in trying to take the utrace
improvements, and scaling down what they promise, and ignoring all input
except for "I want to strace and gdb at the same time".

So stop the crazy "new kernel interfaces" crap. Stop the crazy "maybe we
can use it for ftrace and generic user event tracing too". Stop the crazy.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 17:37:44 UTC
Message-ID: <fa.MBBn5h3vi5sjLSO5qWVFTVxObYo@ifi.uio.no>

On Mon, 25 Jan 2010, Frank Ch. Eigler wrote:
>
> Earlier, you said that you haven't followed utrace "at all".  Upon
> what real information do you infer that it has been over-designed?

Upon the information that people are talking about magic new kernel
interfaces to do fancy things. And talking about doing things with it that
are simply not relevant for ptrace/strace.

In fact, in this very thread I've been informed that there are no user
interfaces to utrace at all, which to me says that it's been TOTALLY
MISDESIGNED FROM THE VERY START, and has nothing to do with making ptrace
work for strace/gdb at the same time.

In other words, I may not have followed utrace development, but I sure as
hell can read. And everything I read about it just makes me less inclined
to want to merge it. The people who argue "for" it are actually screwing
themselves by arguing for all the wrong things, and making me convinced I
don't want to touch it with a ten-foot pole.

If somebody were to argue that "this is a simple series of patches to
clean up ptrace and make it possible to strace a debugged process", then
that would have been different. That's not what you or others have been
doing. You've been pushing exactly the _reverse_ of that, namely how great
it is for some random totally new features that I'm convinced aren't even
used by a lot of people.

So give me a populist argument that makes sense for tons of actual users,
not some f*cking "here's a cool infrastructure that developers can do
random crazy out-of-tree crap with". Because I'm not interested in crazy
developers.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 17:47:20 UTC
Message-ID: <fa./I4vbLgmpVfOthpuryKDS0EICLk@ifi.uio.no>

On Mon, 25 Jan 2010, Linus Torvalds wrote:
>
> So give me a populist argument that makes sense for tons of actual users,
> not some f*cking "here's a cool infrastructure that developers can do
> random crazy out-of-tree crap with". Because I'm not interested in crazy
> developers.

In other words, give me the "killer feature". The thing I've asked for all
the time. The thing that you seem to continually NOT EVEN UNDERSTAND.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 18:14:05 UTC
Message-ID: <fa.JgWiUjfjido9Ok/MOLUJevFzof0@ifi.uio.no>

On Mon, 25 Jan 2010, Steven Rostedt wrote:
>
> Uh oh, that's not good for us real-time folks.
>
> http://lwn.net/Articles/357800/
>
> "And, according to Linus, the realtime people are crazy, so they can be
> left to deal with the weird stuff."

The RT people have actually been pretty good at slipping their stuff in,
in small increments, and always with good reasons for why they aren't
crazy.

Yeah, it's taken them years, and they still have out-of-tree stuff. And
yeah, they had to change some things to make them more palatable to the
mainline kernel - the whole fundamental raw spinlock change is just the
most recent example of that.

But on the whole, I think it's actually worked out pretty well for them. I
think the mainline kernel has improved in the process, but I also suspect
that _their_ RT patches have also improved thanks to having to make the
work more palatable to people like me who don't care all that deeply about
their particular flavor of crazy.

And yeah, I still think the hard-RT people are mostly crazy.

So I can work with crazy people, that's not the problem. They just need to
_sell_ their crazy stuff to me using non-crazy arguments, and in small and
well-defined pieces. When I ask for killer features, I want them to lull
me into a safe and cozy world where the stuff they are pushing is actually
useful to mainline people _first_.

In other words, every new crazy feature should be hidden in a nice solid
"Trojan Horse" gift: something that looks _obviously_ good at first sight.

The fact that it may contain the germs for future features should be
hidden so well that not only is it not used as an argument ("Hey, look at
all those soldiers in that horse, imagine what you could do with them"),
it should also not be obvious from the source code ("Look at all those
hooks I sprinkled around, which aren't actually used by anything, but just
imagine what you could do with them").

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 20:43:27 UTC
Message-ID: <fa.T1NmR1O45NJ/UBbKDrGW8qT4qIk@ifi.uio.no>

On Mon, 25 Jan 2010, Mark Wielaard wrote:
>
> And all these users have wishes to extend the current ptrace interface
> mess. But nobody dares to extend ptrace in any direction because
> fixing/cleaning up one of these use cases might break the others in
> subtle and not so subtle ways. Which is why the utrace series of patches
> is cleaning up all this stuff first.

I call bullshit.

You can clean up ptrace without introducing odd new interfaces and trying
to sell it as some revolutionary new kernel interface that can do
anything.

I also call bullshit on the "ptrace() is so horribly nasty" argument. Yes,
I've seen the code that uses ptrace in user space, and yes, it's nasty,
but it's invariably _not_ nasty so much because ptrace itself is nasty,
but because it's full of #ifdef so-and-so-os/so-and-so-arch, and the code
is never cleaned up.

There are a couple of obvious cases of ptrace being uglier-than-it-needs-
to-be. Like the traditional ptrace read/write interface being purely "word
at a time", and that clearly is not pretty. Several architectures already
do "copy range" kind of versions on it, though, so that's just a detail,
and if anybody wanted to clean it up, they could have.

The more fundamental problem is the use of signals (while at the same time
wanting to _trap_ non-ptrace signals), without any model for a "connection
state", which is why you can have only one tracer. But again, that's
largely a user interface issue, and apparently utrace does _nothing_ for
that problem at all.

So I do agree that ptrace is not a great interface. However: repeating
that statement over and over in _no_ way excuses some totally unrelated
code that doesn't have anything what-so-ever to do with the actual
problems of ptrace.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Tue, 26 Jan 2010 00:10:04 UTC
Message-ID: <fa.m0YJN/h2DaVCtIyCcqvbiPr26Y8@ifi.uio.no>

On Tue, 26 Jan 2010, Renzo Davoli wrote:
>
> The solution is that everybody can code his/her optimized kernel/user
> interface for tracing in his/her kernel module, i.e. utrace.

I don't think people understand. That is simply not a "solution". That is
a PROBLEM. The thing you describe is an absolute disaster. Which is
exactly why I rant against it.

The last thing we want to have is "here, take this, and make your own
kernel module mess around it optimized for your particular crazy
scenario".

But every SINGLE post in this thread that has argued for utrace has argued
exactly this way.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Mon, 25 Jan 2010 21:42:57 UTC
Message-ID: <fa.AcEVc9t1i5wrUBSesmbsqTnIE40@ifi.uio.no>

On Mon, 25 Jan 2010, Tom Tromey wrote:
>
> There are definitely things we would like from such an API.  Here's a
> few I can think of immediately, there are probably others.
>
> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
>   Internally we're already using a self-pipe to integrate this into
>   gdb's main loop.  Relatedly, don't mess with the inferior's parentage.

As I kind of alluded to elsewhere, I heartily agree with this. The really
major design mistake of ptrace (as opposed to just various ugly corners)
is how it has no connection information, and that ends up being one of the
main reasons why you can't have two ptracers working on the same thing.

(There are other things that complicate that too, of course, like simply
just trying to manage various per-thread state like debug registers etc,
but that's a separate class of complications).

> * Support "displaced stepping" in the kernel; I think this would improve
>   performance when debugging in non-stop mode.

Don't we already do that at least on x86? Just doing a single-step should
work on an instruction even if it has a breakpoint on it, because we set
the TF bit.

Or maybe I'm not understanding what displaced stepping means to you.

> * Support some kind of breakpoint expression in the kernel; this would
>   improve performance of conditional breakpoints.  Perhaps the existing
>   gdb agent expressions could be used.

I suspect it might be reasonable to do simple expressions on breakpoints,
but not the kind of things gdb exports to users. IOW, maybe you could have
a single conditional on a single value (register or memory) associated
with an expression.

Regardless, internally to the kernel your two later issues are "details".
The "how to connect to the debuggee" is a much more fundamental issue, and
has the biggest design/interface impact. The other would likely just be
new ptrace command extensions that somebody would have to just implement
the grotty details on.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Tue, 26 Jan 2010 23:39:09 UTC
Message-ID: <fa.PJON4rgIIJ3m4phW03gViUWBwtk@ifi.uio.no>

On Tue, 26 Jan 2010, Tom Tromey wrote:
>
> In non-stop mode (where you can stop one thread but leave the others
> running), gdb wants to have the breakpoints always inserted.  So,
> something must emulate the displaced instruction.

I'm almost totally uninterested in breakpoints that actually re-write
instructions. It's impossible to do that efficiently and well, especially
in threaded environments.

So if you do instruction rewriting, I can only say "that's your problem".

But using the hardware breakpoints should automatically DTRT, both wrt
threads _and_ wrt restarting. Sure, there's onyl a limited number of them,
so if somebody wants more than that they are kind of screwed, but that's
just how life is.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: linux-next: add utrace tree
Date: Tue, 26 Jan 2010 18:47:22 UTC
Message-ID: <fa.9U2FQIssv9C9ao9kwHIhNw8zLNk@ifi.uio.no>

On Tue, 26 Jan 2010, Andi Kleen wrote:

> Tom Tromey <tromey@redhat.com> writes:
>
> > * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> >   Internally we're already using a self-pipe to integrate this into
> >   gdb's main loop.  Relatedly, don't mess with the inferior's parentage.
>
> How would having a kernel based solution be better over your
> user space simulation?

Oh, the reason we should do something in the kernel is that you really
can't do certain things with the ptrace() interface.

For example, think about how Wine and UML use ptrace - and then realize
that that makes it impossible to attach a debugger from the outside.
That's a real deficiency in ptrace - much more so than the fact that there
are some odd details (ie the whole "read/write a word at a time" is just a
quirky detail in comparison - not a fundamental problem).

> BTW there's the new signalfd() system call that might do it
> (haven't checked if it works for SIGCHLD)

No, you miss the point.

The problem isn't that you want to turn signals into a file descriptor
just because you like file descriptors.

The problem is that anything that is based on reparenting and signals is
fundamentally a "one parent only" kind of interface. See?

So the reason I think using an fd is a good idea is _not_ because gdb
already uses an fd internally, but because it gives you a "connection"
between the debugger and debuggee that is not fundamentally limited to a
single controller.

(It doesn't have to be a file descriptor, of course, but could be any kind
of other model that allows multiple connections. It's just that in unix
terms, using a file descriptor as the "cookie" for the connection is a
very natural model. So the important part isn't the file descriptor
itself, it's the model you could build).

			Linus