user_regset ports, get moving!

[Roland McGrath]

Happy New Year, everybody!  For the turning of the winter season (and right
before vacation), I finished the first stage of the new integration plan
in https://www.redhat.com/archives/utrace-devel/2007-November/msg00009.html

See the thread starting at http://lkml.org/lkml/2007/12/20/69
(There was also an earlier thread on lkml about arch_has_single_step.)

All the generic and x86 code is now in the x86's maintainers' mm tree:
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git branch "mm"
This is folded into the -mm patch series, but you can only see the details
of the individual patches from the GIT tree (or the mailing list threads).

This means the x86 maintainers are happy with it, and I hope this will
be going into 2.6.25; noone has complained of it breaking any other arch
in -mm.  I also did the powerpc work and posted it upstream (same
thread), but have gotten no feedback yet.

So now it's time to get other arch ports in shape.  As I mentioned
before, I want to get out of the middle of it ASAP and have someone on
this mailing list become the arch advocate for each arch.  Now is the
time to step forward.  Please post here if you are taking the lead in
the effort for a particular arch to get user_regset changes accepted by 
upstream arch maintainers.  (I am the arch advocate for x86.)

To get started with your arch maintainers, point them to the
aforementioned lkml thread (was also on linux-arch).  If they already
maintain a post-2.6.24 arch tree that goes into -mm, then the x86.git
patch in -mm is all the baseline they need.  If not, the first several
patches in that thread are the generic ones, and only those are required
to start working on arch code.  (If the changes now in the x86-mm tree
get into mainline soon after 2.6.24, then it will be easy for all arch
maintainers.)  To see an example of what an arch's changes look like,
the powerpc patches in that thread are a good reference.

For all the machines that had utrace ports done before, you can reuse most
of that work (utrace-regset-yourcpu patch primarily).  The signatures of
the functions and all the names have changed, but it's about the same as
the utrace_regset code.  Or, it may be a good opportunity to clean up the
arch code incrementally in the process and write the new accessors more
organically.  That's what I did for x86 and powerpc, where there turned out
to be very little cut&paste from the utrace-regset patch.  Figure out what
your arch maintainers want to see.  Feel free to CC me on your user_regset
patches, but send them to the appropriate upstream arch mailing lists and
not to utrace-devel.  If you have feedback/questions about the generic
user_regset patches I posted on lkml/linux-arch, please follow up there
(and to me directly), and not on utrace-devel.  The user_regset changes are
now independent of utrace, and can stand alone on the kernel scene.

I have not done for user_regset an equivalent to ptrace_layout_segment and
related helpers, and might not do that same thing at all.  For the
user_regset work, I would start first with the regset accessors and making
CORE_DUMP_USE_REGSET work.  If your arch maintainers are liking that ok,
then you can move on to cleaning up the ptrace requests incrementally
(and/or switching to arch_ptrace and/or compat_arch_ptrace).  For most
everyone, e.g. GETFPREGS is simple.  If your arch has some hairy legacy
ptrace layouts that don't lend themselves to cleanup using the user_regset
accessors, then talk to me (on lkml) about more helpers that might make it
easier on your arch code.

As soon as at least the generic and x86 changes have gone into Linus's
tree, I will stop maintaining any arch patches in the utrace patch series.
Instead, the utrace code will be based on the user_regset code (and
arch_has_single_step) and will only compile on an arch where user_regset
has been implemented fully.  I hope we'll have several other arch ports
ready to merge by then too.


Thanks,
Roland