utrace_ptrace && task->ptrace

[Roland McGrath]

> Actually the very first "for utrace-devel only" version should be just
> your utrace-ptrace.patch + attach/detach fixes. Not that I can verify
> this, but I hope that ptrace_utrace_ops's methods are more or less right.
> (but of course, we should recheck them as much is possible).

The utrace_ops parts of that code are probably not too far off, but the
rest of it is really no starting place.  Like I've said before, you should
be starting from scratch and just yanking little bits out of that old patch
that are useful.  I'm sure some of the kludge factor will be reduced
greatly by not trying to make it conditional.  But the big wrongnesses are
things like ptrace_set_action() et al.  Not to mention the whole wakeup and
synchronization regime, which is why we had that whole discussion earlier.
(And it's not just not clean, it's known to be buggy!  So it's not to be
presumed a decent guide for anything.)

> Than we can move some things into engine->data. Right now my only concern
> is attach/detach, and the only method which needs the immediate attention
> is ptrace_resumed() which (afaics wrongly) does the "deferred" detach.

I'm open to whatever you like that gets the semantics right.  I can't see
how PTRACE_DETACH with nonzero argument (detach-parting-signal.c case in
ptrace-tests) can be done anything remotely like cleanly unless you keep
the utrace_engine around to have a final report_signal callback.

> I agree, CONFIG_UTRACE_PTRACE should die. But what about !CONFIG_UTRACE
> case? What should we do with arches which doesn't use tracehooks or
> play with ptrace internals?

AIUI hch wants to have ptrace rely on utrace.  Those either get no ptrace
(we cond_syscall it) and/or just stop building if not updated.  Maybe he
can give you some more direct advice about what the merging plan should be.

The tracehook conversion is pretty simple for every arch, even for non-arch
people (if you just punt the syscall-abort support, which is a new feature
and so a non-regressing incremental step).  

> Firstly, these changes can't be applied until we fix arch/ which play
> with ->ptrace.

Only a few arch's overload ->ptrace for private purposes, and I don't
foresee any problem getting those fixed up soon.  (The parisc maintainer is
doing it already.  I think xtensa might have something on deck.  I can do
the arm changes if anybody will ever review and merge them.)

> Also. Currently I do not see how these cleanups can really help for the
> first working version of utrace-ptrace. For example, if we kill task->parent,
> we need more changes for the first version.

Your ptrace code will need to record some state somewhere, beyond the
legacy ptrace fields.  ptrace_ctx hung off engine->data is the natural
place for all that state.  That's why I figured we'd want some of those
cleanups (at least having the struct at all) before doing utrace-ptrace.
In short, I think when you get satisfactorily working ptrace code going
you will have had to do enough new stuff that cleanup beforehand seems
preferable.  But it's up to you.  Get it merged ASAP, get it clean
eventually.  Sometimes getting it clean first helps get it merged,
but maybe not.  Always getting it working well and readably so helps
getting it merged, and sometimes getting it clean helps with those.


Thanks,
Roland