incremental arch work

[Roland McGrath]

> Now that code related to most of the steps you outlined in this thread are
> scheduled to be pushed upstream (thanks a ton for the work!), from a

As yet this is only entirely true for x86.  While I have also done and
posted the work for powerpc, it still needs an advocate to secure the
upstream powerpc maintainers' commitment to fold it in.  (And more
testing, and probably to unbreak kexec.)  For all other machines,
including the ones for which utrace support was implemented before, the
new form of porting work (user_regset) remains to be done.

> - Breakpoint assistance (including single-stepping out of line)

I have written before in some detail about how I think this would
ideally be factored out.  That is just about entirely orthogonal
to the utrace interface.  (There's no reason it couldn't have been
done already.)  

> - Quiescing all threads of a process.

I am skeptical that this alone will be something to factor out in a
useful way as an isolated facility.  (That's not to say there is anything
to stop someone taking a whack at it.  Experimentation is good.)  I've
discussed the subject before.  We can get into it later, when someone is
actually doing something about it.

> - What'd be your suggestions on that front? Do we just base these off of
>   the current utrace engine infrastructure?

The work of making the instruction-copying facility into nice modular
pieces is not going to be affected very much by the utrace interface
details even if they were to change a lot.  I do not anticipate any
really drastic changes to the character of the utrace interface.  If you
write to what we have today, I don't think there will ever be a great
deal of work involved in adjusting to however it comes out in the end.

> - Are the tracehooks and engines the next targets upstream? Possibly
>   2.6.26?

I don't want to speculate about when patches might be accepted upstream
before I even have them composed.  We are indeed just about to the next
major phase now.  We will really be there when user_regset patches go
into Linus's tree, which we expect in the 2.6.25 merge window after
2.6.24 goes out.  This next phase is, frankly, not yet planned out in
much detail.

The overall plan is to be very incremental, giving upstream small chunks
that are easy to digest.  This will require slower work than simply
forward-porting the utrace patch set after the user_regset integration.
At every point, new changes will not break existing functionality.  New
code will be enabled only by new config options.  Each arch must continue
to work unchanged using the old default config options, though it will
only be possible to build using new options on an arch that has done the
user_regset work.

I think what this will mean for me initially is to focus on some cleanup
work in the upstream core ptrace and signals code.  This is tangential to
integrating utrace per se, but it is the right thing for upstream to get
some incremental improvements.  Then I will start incrementally teasing
out the ptrace tendrils into all corners of the kernel, consolidating them
in places like tracehook.h and ptrace.h with coherent entry points (the
same sorts of things that are in utrace-tracehook.patch, but we'll see
exactly how it comes out).  Unlike what utrace-tracehook.patch does, this
work will leave the old ptrace implementation machinery intact, though
some of it moved around and wrapped in more inlines.  I don't think that
much will be especially controversial.  At that point any new thing can be
done touching the rest of the kernel as little as utrace-core.patch does.
That at the very least makes it much easier to maintain an experimental
patch set relative to the upstream tree.

> - Do you have any changes in mind from a utrace-client perspective that
>   we need to be cognizant of?

The only things akin to specific plans I have in mind are those I've
discussed before and that are already on the TODO list.  In particular,
the "engine interaction issues" area comes to mind.  (See
https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and
https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html
for detailed background.)  This is something we are already pretty sure we
need to revamp, so hashing that out before preparing something for
submission seems like a good idea.  Working on a well-heeled breakpoint
facility that manages in the presence of other engines both to work right
and not to confuse the other engines would is a fine way to pin down the
concrete details of those interface changes.

It's altogether possible that many other things will change in the course
of ironing out the code upstream.  Off hand the kind of changes that seem
most likely aside from cosmetic things are in the handling of allocation
and data structure lifetimes.  Those are important things, but usually not
big parts of how the client code is organized to use the interface.
I don't think you need to worry about them ahead of time.

To be honest, I think strong development of things exploiting utrace
heavily will have more effect on how the interface mutates to get merged
upstream than vice versa.  Proving the utility and need for certain
interface details concretely by using them enough to care about the
subtleties gets more traction (and hones better interfaces) than any
amount of pontification I might muster.


Thanks,
Roland