Hi folks. Sorry for the long silence. I have been working on the utrace rebase/new upstream integration, but as usual other work got in the way. This week I took a break from the slow and steady hacking towards clean integration, to hack and slash a rebase that works again.
I have stopped maintaining the old GIT repository, though it did get a few fixes just before I switched development over to the rebase. http://people.redhat.com/roland/utrace/2.6.24/ has what was in 2.6-current/ until recently. That matches the old GIT repository, which is still accessible as before. The new code is relative to upstream shortly after v2.6.25-rc6, precisely GIT commit 264e3e889d86e552b4191d69bb60f4f3b383135a. (Maybe rebased again by the time you read this.) For the moment, I have not set up a pretty patch series like before. There is the unceremonious one big patch at: http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch The way to track my hacking up to the minute is to use the new GIT repository. git remote add utrace git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git git remote update Browse at: http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-utrace.git;a=summary I have not really figured out yet how I will organize the GIT branches or patch series. I am still often updating the new repository with "git rebase" rather than "git pull". So if you fork your own GIT branches off my branches, you won't be able to use git merging to track (but you can use git rebase). If this is a royal pain for you, let me know. >From that repository you will now have the following branches. I am maintaining these as patch sets prepared for submission rather than as normal GIT branches. So the each commit in a branch will be a polished patch to submit upstream, rather than incremental fixes for the branch. * utrace/cleanup These are patches I've already posted upstream, or will very soon. I expect them to be noncontroversial, but they are probably too late for 2.6.25 already. These are all harmless and safe cleanups and fixes that should not break or perturb the vanilla kernel at all. They are prerequisites for utrace, but not specific to utrace. * utrace/tracehook These are patches in roughly the form I expect to submit upstream. They do not have proper log entries yet. I will probably change their contents around some more. This series won't be submitted until all the later series to complete the integration are ready. But, these are "clean" patches that are ready for review feedback from anyone who wants to look. These patches leave the old ptrace working as it is, and should be a compiled away no-op change to the vanilla kernel. They do not do very much of what was in the old 2.6.24/utrace-tracehook.patch. * utrace/utrace-tracehook These are unfinished pieces somewhere in between the old code and being ready for the "clean" utrace/tracehook branch. I still need to work out the clean integration for these tracehook entry points. These ones fill out what utrace needs to work as it did before. * utrace/die-ptrace-die This branch is just one patch, actually. It's a quick and dirty job of ripping out the old ptrace code. This does much of what was in the old 2.6.24/utrace-tracehook.patch, like removing task_struct.parent. I punted the renaming of real_parent to parent. This leaves a kernel that should work fine but has a ptrace syscall that always gets ENOSYS. * utrace/utrace-core This too is just one patch. It's the same as the old utrace-core.patch, the heart of the utrace code. Nothing really changed. With this, you can use utrace modules (I tested crash-suspend.c). * utrace/utrace-ptrace The utrace/master branch is another name for this. If you got the repository with git clone, you should be tracking this branch. This adds ptrace-on-utrace, much the same as the old 2.6.24/utrace-ptrace-compat.patch did. Not much has changed here either. The current status is that things seem to work on x86 (no regressions in the gdb test suite). I have only just started testing powerpc and it looks a little broken, probably ironed out soon. I expect to put the new code into the Fedora 9 development kernel this week. If you were used to the old patch series/GIT branches, here are the things will notice: Firstly, there is no utrace-regset.patch any more. The upstream user_regset (linux/regset.h) code takes its place. There is now (almost) no arch code in the tracehook or utrace-ptrace branches either. The upstream arch_has_single_step et al and various ptrace cleanups cover the rest of the machine-dependencies. As of 2.6.25-rcN the arch support is now an upstream responsibility. There are some necessary arch patches in the utrace/cleanup branch, but hopefully those will go in soon. I think the only machines with necessary support included in 2.6.25-rc6 are x86, powerpc, and sparc64. If you need pointers on getting an arch in shape, please ask here. The utrace interface is unchanged except that struct user_regset replaces struct utrace_regset. The regset accessor functions don't take the engine as an argument any more, but are otherwise the same. The task_struct.real_parent field is back. I decided not to bother with renaming it to parent, since it's just unnecessary churn in the patches for a divergence from upstream that's purely cosmetic. Change your utrace module code to use ->real_parent instead of ->parent. I will be working on more cleanup in the coming days. Before it's all ready for submission, I think there may be substantial changes. I'll write more here as it develops. Thanks, Roland
