Re: [PATCH 2/2] utrace: ptrace cooperation

[Roland McGrath]

> I don't like this patch in it's current form.  Having two different ways
> to do ptrace is a rather awkward thing and not very good for testing
> coverage.  This should not be an option but required.  

The main idea behind having CONFIG_UTRACE_PTRACE be an option separate
from CONFIG_UTRACE is just for debugging during this development and
transition period.  With CONFIG_UTRACE=y, CONFIG_UTRACE_PTRACE=n, then
ptrace works as it ever did.  You'll only have trouble if you use utrace
on the same tasks.  So if you hit bad problems working on something
using utrace, you can always switch to CONFIG_UTRACE_PTRACE=n to use gdb
and strace et al reliably on your userland code, which might be damn
helpful in figuring out how you're triggering the utrace bugs.  By the
time it's no longer EXPERIMENTAL, the separate option could be gone.

> I'm not even sure
> keeping a non-utrace version at all is a good idea. I'd rather set a
> deadline for arch maintainers to convert everything to the generic
> ptrace bits + regsets + tracehook and if they don't manage to do it by
> then ptrace will be disabled for those who can't keep up.  Of course
> this will need an announcement on linux-arch first, but it's much better
> than a never ending phase of APIs in migration.

We agree on how it should end up.  I have concentrated on how not to
break any arch that doesn't care about my work, or put another way, how
not to let progress be held hostage to delay as long as some arch's
don't care.  An arch deadline is fine with me (I'm not the one who has
to meet it).  I've always assumed there would be one eventually.  But
any reasonable deadline would be some time hence, I don't know how long
(time scales in feature-removal-schedule.txt seem to be pretty long).  I
wouldn't like to make merging any of utrace be contingent on waiting for
that deadline, just to avoid having a phase of APIs in migration--one
that can certainly end.

There is another point, not about the arch issue.  In the first utrace
prototype, I wound up spending basically all my time on ptrace.  An
internal reorganization that implements ptrace is not very interesting.
I think that working on different users of utrace will be far more
effective at honing the utrace layer.  My hope is that utrace can be
merged and EXPERIMENTAL for some time while users develop, beat on, and
get it solid.  Meanwhile, people not working on that need reliable old
ptrace code when they don't select the newfangled options.

As the patch posting said, this is a minimal kludge to get by for now.
After some of those other users you've demanded have banged it all out,
then I'll get back to worrying about ptrace later.  (In the meantime, if
it goes too wrong, switch back to the old code while we keep hashing out
utrace bugs by other means.)

Some more ptrace cleanups can be done orthogonal to utrace,
e.g. reorganizing the data structures as you mentioned in another
message.  This can be done in parallel to getting utrace in shape.
Doing it that way makes it easy to test and prove those cleanups on
their own and thus isolate any ptrace regressions either to those
changes or to utrace problems.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/