Date:	Sun, 24 Jan 2010 13:01:21 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	tytso@....edu, Ingo Molnar <mingo@...e.hu>,
	Kyle Moffett <kyle@...fetthome.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	utrace-devel@...hat.com, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree

Hi -

tytso wrote:
> [...]

Let me see if I can paraphrase those of your concerns that were substantive:

1) That if utrace is merged, and systemtap keeps on using it, there may be
   some sort of chilling effect on kernel developers that would impede
   utrace's future development.

This might sound plausible to an outsider, but luckily we're not stuck
with having to speculate: one can examine history.  Systemtap has been
around, working roughly the same way, for about *five years*.

Systemtap modules use more than a handful of mainstream
module-accessible kernel services.  During all this time, how many
examples have there been when when systemtap developers have pleaded
with lkml to avoid changing some prior interface?  How many of those
successfully?  (That last one is a trick question, since both numbers
are really close to *zero*.)  How much real impediment to change has
our mere existence caused?


2) That systemtap is not portable to all kernel versions.

Problems do periodically occur.  However, one can again refer to
historical facts to assess whether in fact they warrant long term
grudges.  In every release note, we list the range of kernel versions
we test against.  We may have one of the broadest ranges of support,
2.6.9 through to many current -rc*s and non-linus trees.  We have
several mechanisms which let us easily adapt to most changes.  It may
interest readers to find out that the number of systemtap changes we
have had to add on account of kernel changes is on the order of a *few
per year*.  The usual turnaround, once reported, is on the order of a
*few days*.


3) That systemtap users will complain to kernel developers if
   systemtap becomes incompatible.

Let's go to the historical record again.  How many such complaints
have actually been seen in inappropriate fora such as lkml?  How
difficult were they to diagnose / redirect to the proper venue?  Have
they constituted a "loss of face" for kernel developers?


4) That systemtap is almost but not quite as evil as nvidia.

It seems factors like ...

- always being completely open source project
- keeping in regular contact with lkml and other constituencies
- not being related to essential hardware enablement, so users
  not wanting it don't have to touch it
- the compile-to-C approach being technologically necessary since
  there was no alternative plausible way at the time (and still now)
- repeatedly offering infrastructure code with non-stap uses

... all add up to a mere nudge away from entirely "evil".  If so, I
wonder if your sort of grossly bimodal view of ethical virtue is going
to foster the right sorts of change in the linux kernel community.


- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists