Re: Discussion at Linux Foundation Japan Symposium

[Roland McGrath <roland at redhat dot com>]

Picking up the discussion after the holiday break.  Happy New Year.

> How much more utrace work is needed?  Fedora is shipping it, right?
> What still needs to be done before it can be merged?  The
> characterization that I heard at the plumber's conference was that the
> work was largely done, and it was just a matter of it getting merged.

It is largely done in the sense that it is a new experimental in-kernel API
that we can use now and that will surely get thrashed and refined as we go
on.  I would certainly like to see it merged sooner rather than later, and
then improved in the tree.

The code at http://people.redhat.com/roland/utrace/ and also in
git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git
is based on the current Linus tree and can merge painlessly.

Since 2.6.2[78], the whole of the new code is utrace proper, and all under
the CONFIG_UTRACE option, which "depends on EXPERIMENTAL".  However broken
utrace might be, you can configure it out and have my patches make zero
code changes in your kernel.

I had hoped that this zero impact for the uninterested would make the
threshold of acceptance for merging utrace reasonably attainable without
much controversy or rigamarole.  However, in various recent conversations,
several kernel folks said we should not submit utrace on its own at all.
They told us a new in-kernel API can't go in without something that uses
it, and "systemtap doesn't count".  They want us to come up with some
completed kernel feature, small or large, that makes use of utrace to do
something or other, that they like and want to merge.  Only then, they
said, should we submit utrace patches, along with more patches adding this
thing that uses the utrace API.

That seems counterproductive to me, frankly.  Since you seem to be
encouraging me to just get utrace merged ASAP, I hope you agree with my
view here.  Everyone who ever says they'd like to help writing nice, useful
things based on the utrace API complains about utrace not being merged and
that this discourages work based on it.  Now other people say that it
mustn't be merged until people have done that work.  Catch 22.
(Everybody's way out is for me to just write everything, apparently.  
Silly other people want me to also work on other projects entirely at the
same time, so this idea has not been getting things done quicker.)

I agree with your attitude about bugs.  If it's merged, we will fix and
change it in the tree as we hash out problems.  People at large find it
easier to consider, test, or help work on the code that way.  It would
certainly be easier for me and for the systemtap community.  People who are
concerned it might be unstable can see "EXPERIMENTAL" when configuring
their kernels and just say "n" (CONFIG_UTRACE is off in defconfig).

Since the kernel summit I got in little time to actually do very much, so
there's really a moderately small amount of change since then.  I had fixed
several bugs and introduced more regressions along the way.  Just today I
finally got a little time to get back to it and fixed most of the
regressions, so it's not in a pathological state.  But it presently has at
least one known intermittent regression in ptrace and a WARN_ON that I'm
confused about, and I'm not certain that it can't still be crashed by some
of the test cases that LKML reviewers showed before (though our suite has
variants of those tests and I haven't seen any crashes lately).  (I'll be
spending some time on the known bugs, but a fairly constrained portion of
my time.  It still remains to be seen what can be done about getting other
hackers' eyeballs active on fixing code in this layer.)

So, please advise me.


Thanks,
Roland