tracehook submitted, branch juggling, arch howto

[Roland McGrath]

I've submitted the patches from the ptrace-cleanup and tracehook branches
upstream.  http://marc.info/?l=linux-kernel&m=121628237024384&w=4
We'll see how that goes.  If you care about utrace or about having
better user-debugging facilities in the kernel at all, please lend
your voice on LKML to have this work go in upstream ASAP!

In preparation for submitting the patches, I juggled the branches around a
bit again.  The ptrace-cleanup, tracehook, and utrace branches are as
before, but don't contain any of the arch patches.  There are now new
branches forking from tracehook for {x86,powerpc,sparc64,ia64}-tracehook.
This arrangement better matches how GIT branches are used upstream with
arch maintainers.

There are separate cpu-tracehook.{patch,mbox} files to fetch if you are
applying the patches individually (or from the mbox's with git-am).

As always, linux-2.6-utrace.patch rolls in everything.  This is the same as
the branch "master".  It's a simple merge of all the branches, to get a
tree with arch support and utrace that you can build from.  So that's what
you'll get from a simple:

	git-clone git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git

I added the page http://sourceware.org/systemtap/wiki/utrace/arch about
arch stuff.  Feel free to amend it.  Especially if anyone is interested
in one of the arch's not finished (i.e. all but x86 & powerpc), please
add a row to the table.  The utrace/arch/HowTo page linked from there has
pointers for the person writing the arch code.

If the world is kind to us, these generic patches will be merged soon, and
we can start working with arch maintainers to fill in their pieces.  

I would dearly love to stop spending all my time rebasing and fiddling with
the tracehook patches, which is where far too much keeps going as long as
we have so much of the work not in upstream.


Thanks,
Roland