Re: [RFC,PATCH 0/14] utrace/ptrace

[Oleg Nesterov <oleg@redhat.com>]

On 11/25, Christoph Hellwig wrote:
>
> On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote:
> > Hello.
> >
> > This is the new iteration of Roland's utrace patch, this time
> > with "rewrite-ptrace-via-utrace" + cleanups in utrace core.
> >
> > 1-7 are already in -mm tree, I am sending them to simplify the
> > review.
> >
> > 8-12 don not change the behaviour, simple preparations.
> >
> > 13-14 add utrace-ptrace and utrace
>
> Skipped over it very, very briefly.  One thing I really hate about this
> is that it introduces two ptrace implementation by adding the new one
> without removing the old one.

Yes, we obviously need the old one when CONFIG_UTRACE is not enabled.

So, I'd like to try to restate: one thing we all really hate is that
CONFIG_UTRACE exists.

> Given that's it's pretty much too later
> for the 2.6.33 cycle anyway I'd suggest you make sure the remaining
> two major architectures (arm and mips) get converted, and if the
> remaining minor architectures don't manage to get their homework done
> they're left without ptrace.

Well, I can't comment this. I mean, I can't judge.

> The other thing is that this patchset really doesn't quite justify
> utrace.  It's growing a lot more code without actually growing any
> useful functionality.

This should be clarified. I don't think ptrace-utrace adds a lot more
code compared to the old ptrace. Note that we can kill a lot of old
code once CONFIG_UTRACE goes away. ptrace_signal(), ptrace_notify(),
even task_struct->almost_all_ptrace_related can go away.

kernel/utrace.c does add 12280 bytes (on my machine), yes.

> What about all those other utrace killer
> features that have been promised for a long time?

It is not clear how we can expect the new "killer" modules/applications
which use utrace before we merge it.

We already have some users, say, systemtap. But I don not know
what can be counted as a "really killer" application of utrace.

Oleg.