[PATCH] Embed struct utrace in task_struct - V2

[Roland McGrath]

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
  
* 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.


Thanks,
Roland