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.
First, the common groundwork (maybe 2 or 3 arch-independent patches): I envision a new linux/regset.h defining the regset types and helpers from linux/tracehook.h, but with utrace_regset renamed user_regset throughout. Next, the ptrace_layout stuff and helpers from the utrace-ptrace-compat patch go into linux/ptrace.h in fairly similar form (but no utrace references). Also, I will make another generic patch to fs/binfmt_elf.c giving it the option to use user_regset as its only access to machine state (instead of the current asm/elf.h macros on each arch). Next, each arch has several steps. It would be good if someone took my old write-up http://people.redhat.com/roland/utrace/utrace-arch-porting-howto.txt and these notes and synthesized new instructions for doing the "user_regset" cleanups from scratch on an arch (independent of utrace). 1. asm/tracehook.h functions, i.e. single_step et al. Define these called user_* instead of tracehook_*, declare them in the __KERNEL__ part of asm/ptrace.h. I'll probably simplify the macro bits a bit and drop the is-enabled hook that nothing uses. The tracehook_{enable,disable}_syscall_trace functions can just be dropped. Everything uses TIF_SYSCALL_TRACE uniformly for that now. You're just taking the bits from your arch's utrace-tracehook or utrace-regset patch that does this and changing the names. Most of those patches were just renaming existing functions anyway. In some cases the arch code has to change so it can be called on current and not just on another stopped thread. This is not strictly necessary for ptrace cleanup, but will be required for the full generality of something like utrace. It's already done in your arch utrace-tracehook patch, since utrace requires it now, so you do have the code on hand and have tested it. But convincing an arch maintainer to accept that part of the patch has to rely on the argument that it will be good for the future benefit of new debugger features and their future implementation details staying out of the arch maintainers' hair. Update the calls in your arch's old ptrace code to the new names. When every arch has consolidated its code into user_enable_single_step et al functions with standard signatures, we can move PTRACE_SINGLESTEP, PTRACE_CONT, etc. from the arch ptrace code into the generic code. #1 depends on nothing else. 2. arch regset functions, and define task_user_regset_view (new name for utrace_native_view). This is in the utrace-regset patch for your arch now. How to organize this for upstream submission will depend on the details of the code for your arch and what your arch maintainers want. If your utrace-regset patch mostly adds entirely new functions for the utrace_regset (now user_regset) accessor style, then you can do an incremental patch just adding new stuff without changing anything to actually use it yet. If your patch reuses old ptrace code more directly by turning it directly into the regset functions, then you may need to roll this into one patch with the ptrace_layout bits (below) to have something to send upstream in one patch that doesn't break anything. Note that these functions need to incorporate one wrinkle beyond just wrapping the old code in the new accessor signatures. This is already handled in your utrace-regset patch (and is noted in the old porting howto), but may need careful attention to preserve and justify in the upstream arch maintainers' merge. That is, the accessors can be called on current. For the get calls, this is necessary to use them for core dumps, so that should be an easy argument to make. For the set calls, you have to rely on the argument that it will be good for the future benefit of new debugger features and their future implementation details staying out of the arch maintainers' hair. #2 depends on nothing else but the generic patch adding linux/regset.h 3. Use regset functions for core dump. This will just be defining a new macro in asm/elf.h that tells the new fs/binfmt_elf.c code that's what you want. For each arch it could probably be one patch adding that macro and a second patch removing all the asm/elf.h macros no longer used. For arch's with compat, another pair doing that for its compat hack that #include's fs/binfmt_elf.c. #3 depends on #2 4. Use regset functions for ptrace. This is in the utrace-ptrace-compat patch for your arch now. Depending on your code, you might need to roll this into #2 to avoid breaking anything in that patch while still avoiding unpleasant duplication of code that should be cleaned up directly. This should be trivial, and hopefully noncontroversial upstream if #2 has any traction. It's just making arch_ptrace use the ptrace_layout stuff or ptrace_regset helpers for its PEEKUSR, GETREGS, etc. Depending on your arch maintainers' taste, this might be several little patches for each read/write pair of ptrace requests, or just one patch. #4 depends on #2 and the generic patches providing the ptrace_layout helpers 5. arch cruft removal. After all those have been merged, there may be some unused code or macros lingering around from the old ptrace or core-dump support that can be cleaned out. Make it tidy. Except for the dependencies noted, all of these things across the various arch's can proceed in parallel. I hope that these patches will have some appeal to arch maintainers as pure cleanup and consolidation. It reduces the duplication between ptrace and core-dump that arch code has to provide functions and easy-to-miss magic macros for. It provides a single coherent place for an arch maintainer to look for what they should do to cover all userland needs for debugging and dumps. The non-regset cleanups will make it possible to reduce the amount of arch ptrace code now required and keep non-arch ptrace details out of that arch code. This work can be merged into each arch tree more or less right now. That takes me, and any hairy issues about utrace/ptrace, out of the loop for upstream review and merging. I'd still like to stay CC'd on patches related to this sort of thing. But now we can really have the arch maintainers (and the people on this list interested in each arch) "own" this arch code. (That was my hope from the beginning, but in practice they've all been "my baby" and others working on them go through me.) Once the first arch adopts the work to get the ball rolling, I hope for each arch an advocate (other than me) can take the lead in ironing out these cleanups with the upstream arch maintainers. I will get started on the groundwork patches and do x86 to set the example. I think I can get this going in the next few days (next few business days anyway, not sure about the holiday weekend right now). 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. Thanks, Roland
