Thanks very much for your interest in utrace! > 1- Order of callbacks This subject is on the TODO list, part of "Engine interaction issues". You are not the first to bring it up. I'd like to discuss the question more broadly before considering a particular change to the behavior. I'll do this in a separate thread. I'd also encourage you to write up thoughts about things like this on the wiki (make new pages under http://sourceware.org/systemtap/wiki/utrace/), if you are so inclined. > 2- Access to traced process vm. I didn't include any interfaces for this in the utrace core, because there isn't really any need. That is, there is no direct interaction with utrace internals required. Some utrace-using kernel code can just do the memory access itself, perhaps after using utrace to get threads quiescent (and call writeback, for ia64). You can use access_process_vm, or do something in more specific code that does what it does, i.e. use get_user_pages. In recent versions, access_process_vm is no longer exported to modules (though maybe it will be again). But get_user_pages is, and access_process_vm is a pretty simple function anyway. I'm not at all against some new, convenient, exported calls for doing this. But they do not need to be part of the utrace core. I think you should just use whatever is convenient to use in your own code now. When there are a few different things satisfying their own very similar needs like this, then something will gel for new shared interfaces to use. > 3- In the patch I have also implemented the support for PTRACE_MULTI > and PTRACE_SYSVM. Personally, I am not interested in additions to the ptrace interface at all. I don't intend to talk you out of doing it. I completely sympathize with your approach of adding what you most need to the facility that is already working now, and we do not yet have any nice post-ptrace user-level interface in production. I just don't care to comment on the details and merits of any new ptrace requests. What I am very interested in are two things about your work. First, what issues come up with the utrace/tracehook calls in detail in your work? (This being things aside from the engine interaction question.) In particular, tracehook_syscall_* come to mind. Are those doing what you need? Second, what needs/desires/bottlenecks in a higher-level tracing interface do you think are particular to the VM implementation case? Doing more operations with fewer context switches is a universal and well-known need, that anyone designing a new interface is well aware of. If there are unusual needs or usage patterns peculiar to your kind of use, I'd like to get more details about those into discussion. Doing tracehook_abort_syscall and fetching those details from the registers portably is the only thing I think of off hand. For some x86 stuff, maybe there is segmentation magic to be done too? In future, I think it would be most useful if you publish your changes as a series of separate patches (a la quilt). If you make a utrace core change, put that in a separate patch. If you add some utility function, separate the patch for that. Put your ptrace additions in a patch that's just about that. Then it's easier to review each piece of the puzzle on its own merits. Thanks, Roland
