Roland McGrath <roland <at> redhat.com> writes: > > Hi, Ananth. Sorry everything has slid so long (again). > (I have far too many hats and the past month not so many brains!) > > 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. > > 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.) > > 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 >
hi, i've been looking at the patch at the utrace.patch at: http://people.redhat.com/roland/utrace/2.6-current/ hopefully, that's the latest one. Anyways, i'm still looking it over, but one thing that sticks out for me along these lines are the memory barriers and usage of utrace->reporting. It seems that this field is being used exclude utrace_control when we are in the middle of a callback. however, there aren't any comments about the memory barriers and logic here, so its hard for me to tell if its correct... thanks, -Jason
