On Tue, Nov 20, 2007 at 08:29:19PM -0800, Roland McGrath wrote: > 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.
... > 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. 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 (!ptrace) utrace client point of view, the two major remaining components would be the tracehooks and the engine infrastructure. We have quite a bit of code in the uprobes codebase that would be of interest to the larger utrace-client community. These include: - Breakpoint assistance (including single-stepping out of line) - Quiescing all threads of a process. >From a utrace-client (and long term maintenance perspective), we'd like to factor these out. (It'd also make the uprobes codebase much leaner). - What'd be your suggestions on that front? Do we just base these off of the current utrace engine infrastructure? - Are the tracehooks and engines the next targets upstream? Possibly 2.6.26? - Do you have any changes in mind from a utrace-client perspective that we need to be cognizant of? Please advise. Ananth