On Mon, Mar 02, 2009 at 04:07:54AM -0800, Roland McGrath wrote: > Hi, Ananth. Sorry everything has slid so long (again). > (I have far too many hats and the past month not so many brains!)
I understand. Thanks for the work, Roland. > Here is my immediate agenda for utrace hacking: > > * I have incorporated the "embed struct utrace" changes. > > I did various small bits of reorganization and cosmetic cleanup > first to make the actual data structure change a smaller patch. > Since things had changed around, I didn't actually use your patch. > I just did it over myself, but I think it's nearly the same. The changes look simple and straightforward. > After this change, we now need some fresh testing of things like Frank's > ftrace widget and stap's utrace-using modes. (Nothing should have > changed from the utrace API perspective.) There is at least one change from the earlier behaviour -- rather than utrace_attach_task() retrying by itself on a !parent attach, -EAGAIN is returned to the user. That may need changes to the utrace client side. > I've created the new branch "utrace-indirect" with a revert of the > change. I think this is really the better way to organize the data > structures, as I've mentioned before. After we get an initial utrace > merged in upstream, I intend to revive this branch and turn it into an > incremental patch to (re-)improve the data structures later on. That's > for later; for the time being, the branch will just sit idle. > > * I've renamed "struct utrace_attached_engine" to "struct utrace_engine". > This was a cosmetic suggestion in an earlier LKML review, and I could not > really find any good reason to keep the longer name. We all seem to say > "a utrace engine" in conversation when talking about this object. > > I added the UTRACE_API_VERSION macro to ease existing utrace-using code > adapting to old/new names. > > * I'll shortly scour the old review comments for more cosmetic things we > might change. > > * I would like to have a final "in-team" top-to-bottom review of the main > utrace patch before sending to LKML. i.e. maybe by you, Frank, me, and > Oleg. > Each pair of eyeballs should: > * make sure all barriers and other kinds of magic have adequate comments > explaining why they are there and why they are correct > * cite anything else that sticks out and maybe needs more comments > * make sure all comments are accurate and understandable I have just started staring at the new code and will pitch in with my comments. > * I want to resolve the UTRACE_STOP issues Renzo Davoli raised. > (We don't have to get these API things perfect before posting upstream. > I'm sure that once utrace is accepted on queue for merging, that later > tweaks to its details will not meet particular resistance.) But if there > are problems and changes we can identify and work out now, we might as > well get that done before posting upstream. > > * When we on the team think the utrace patch is ready to post, we need to > do a coordinated post of Frank's ftrace widget. That is the first thing > ready for upstream submission that uses utrace, and kernel people tell me > they don't want to see utrace without also merging something that uses > it. I don't really want to get involved with that widget's code myself > (got my hands full in the utrace layer), so others on the team should > back Frank up on the review, testing, and fixing of the ftrace widget. I've just started with implementing a non-disruptive application core dump. Its probably too early to commit, but it could also be a potential in-kernel user of utrace. I've just started with quiescing all threads but need to plug-in the core generating infrastructure for it. I am looking at the possibility of tweaking do_coredump() to reuse it for this while the workhorse can just be the binfmt->core_dump() itself. Its still in the early prototype stage -- I'll post that when there is something more concrete. Ideas/suggestions welcome! Ananth