> 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
As yet this is only entirely true for x86. While I have also done and posted the work for powerpc, it still needs an advocate to secure the upstream powerpc maintainers' commitment to fold it in. (And more testing, and probably to unbreak kexec.) For all other machines, including the ones for which utrace support was implemented before, the new form of porting work (user_regset) remains to be done. > - Breakpoint assistance (including single-stepping out of line) I have written before in some detail about how I think this would ideally be factored out. That is just about entirely orthogonal to the utrace interface. (There's no reason it couldn't have been done already.) > - Quiescing all threads of a process. I am skeptical that this alone will be something to factor out in a useful way as an isolated facility. (That's not to say there is anything to stop someone taking a whack at it. Experimentation is good.) I've discussed the subject before. We can get into it later, when someone is actually doing something about it. > - What'd be your suggestions on that front? Do we just base these off of > the current utrace engine infrastructure? The work of making the instruction-copying facility into nice modular pieces is not going to be affected very much by the utrace interface details even if they were to change a lot. I do not anticipate any really drastic changes to the character of the utrace interface. If you write to what we have today, I don't think there will ever be a great deal of work involved in adjusting to however it comes out in the end. > - Are the tracehooks and engines the next targets upstream? Possibly > 2.6.26? I don't want to speculate about when patches might be accepted upstream before I even have them composed. We are indeed just about to the next major phase now. We will really be there when user_regset patches go into Linus's tree, which we expect in the 2.6.25 merge window after 2.6.24 goes out. This next phase is, frankly, not yet planned out in much detail. The overall plan is to be very incremental, giving upstream small chunks that are easy to digest. This will require slower work than simply forward-porting the utrace patch set after the user_regset integration. At every point, new changes will not break existing functionality. New code will be enabled only by new config options. Each arch must continue to work unchanged using the old default config options, though it will only be possible to build using new options on an arch that has done the user_regset work. I think what this will mean for me initially is to focus on some cleanup work in the upstream core ptrace and signals code. This is tangential to integrating utrace per se, but it is the right thing for upstream to get some incremental improvements. Then I will start incrementally teasing out the ptrace tendrils into all corners of the kernel, consolidating them in places like tracehook.h and ptrace.h with coherent entry points (the same sorts of things that are in utrace-tracehook.patch, but we'll see exactly how it comes out). Unlike what utrace-tracehook.patch does, this work will leave the old ptrace implementation machinery intact, though some of it moved around and wrapped in more inlines. I don't think that much will be especially controversial. At that point any new thing can be done touching the rest of the kernel as little as utrace-core.patch does. That at the very least makes it much easier to maintain an experimental patch set relative to the upstream tree. > - Do you have any changes in mind from a utrace-client perspective that > we need to be cognizant of? The only things akin to specific plans I have in mind are those I've discussed before and that are already on the TODO list. In particular, the "engine interaction issues" area comes to mind. (See https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html for detailed background.) This is something we are already pretty sure we need to revamp, so hashing that out before preparing something for submission seems like a good idea. Working on a well-heeled breakpoint facility that manages in the presence of other engines both to work right and not to confuse the other engines would is a fine way to pin down the concrete details of those interface changes. It's altogether possible that many other things will change in the course of ironing out the code upstream. Off hand the kind of changes that seem most likely aside from cosmetic things are in the handling of allocation and data structure lifetimes. Those are important things, but usually not big parts of how the client code is organized to use the interface. I don't think you need to worry about them ahead of time. To be honest, I think strong development of things exploiting utrace heavily will have more effect on how the interface mutates to get merged upstream than vice versa. Proving the utility and need for certain interface details concretely by using them enough to care about the subtleties gets more traction (and hones better interfaces) than any amount of pontification I might muster. Thanks, Roland