From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13210 invoked by alias); 8 Jan 2009 09:22:49 -0000 Received: (qmail 13201 invoked by uid 22791); 8 Jan 2009 09:22:48 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_50,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Jan 2009 09:22:41 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n089MdjD008215 for ; Thu, 8 Jan 2009 04:22:39 -0500 Received: from gateway.sf.frob.com (vpn-12-162.rdu.redhat.com [10.11.12.162]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n089Mdh5021876; Thu, 8 Jan 2009 04:22:39 -0500 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9C5F8357B; Thu, 8 Jan 2009 01:22:37 -0800 (PST) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 68B01FC3E2; Thu, 8 Jan 2009 01:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Theodore Tso X-Fcc: ~/Mail/utrace Cc: "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium In-Reply-To: Theodore Tso's message of Tuesday, 23 December 2008 17:32:17 -0500 <20081223223217.GW23723@mit.edu> References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081223211306.67D29FC3B7@magilla.sf.frob.com> <20081223223217.GW23723@mit.edu> Message-Id: <20090108092237.68B01FC3E2@magilla.sf.frob.com> Date: Thu, 08 Jan 2009 09:22:00 -0000 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00065.txt.bz2 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