incremental arch work

[Ananth N Mavinakayanahalli]

On Tue, Nov 20, 2007 at 08:29:19PM -0800, Roland McGrath wrote:
> Here are the steps I have in mind.  I think this work should be pretty well
> clear to merge upstream without much controversy.  Basically, this is the
> arch parts now done in the tracehook and regset patches, with a little
> sugar.  Several of these steps can be done in parallel and merged upstream
> independently.

...

> Once upstream arch code has merged all the steps above, there will be no
> more arch changes--or very nearly none, anyway--required to work with a
> later merging of utrace or something else like it.  I've thought about
> ways to be more incremental about the core changes, too.  But if we can
> get the ball rolling with the arch changes and get a majority of upstream
> arch trees converted over, that will be a first big win.

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
(!ptrace) utrace client point of view, the two major remaining components
would be the tracehooks and the engine infrastructure.

We have quite a bit of code in the uprobes codebase that would be
of interest to the larger utrace-client community. These include:

- Breakpoint assistance (including single-stepping out of line)
- Quiescing all threads of a process.

>From a utrace-client (and long term maintenance perspective), we'd like to
factor these out. (It'd also make the uprobes codebase much leaner).

- What'd be your suggestions on that front? Do we just base these off of
  the current utrace engine infrastructure?
- Are the tracehooks and engines the next targets upstream? Possibly
  2.6.26?
- Do you have any changes in mind from a utrace-client perspective that
  we need to be cognizant of?

Please advise.

Ananth