[Ksummit-2009-discuss] Meeting userspace requirements

[Theodore Tso]

On Sat, Jul 11, 2009 at 06:54:18PM -0500, James Bottomley wrote:
> 
> OK, so looking at the above I think there are three classes of people
> requesting features...
> 

There are multiple different ways we can divide up the classes of
people requesting features.  So let me offer up another taxonomy that
might be useful when we try to consider what we might try to discuss
at the kernel summit.

1.)  The user/consumer who either is, or has direct access to, a
"core" Linux kernel developer.  There are two aspects of what I mean
by a "core" kernel developer.  First, this is someone who knows what
kernel development community's coding standards, and will refuse to do
a "hack job" just to get some feature into mainline kernel, and
secondly, he is someone who is generally *trusted* by Linus and the
core kernel community to having these characteristics.  For these
people, they can either do things via a separate sublist (e.g., Dave
Miller and netdev), or on the main LKML (e.g., Ingo Molnar and x86),
and the choice doesn't really matter quite as much.  We don't like to
admit it much, but sometimes something marginal that would be rejected
out of hand if it had been advanced by someone who wasn't a "core"
developer will be accepted (or not even noticed/questioned) if it
comes from a "core" developer.  This is not necessarily mean something
nafarious; sometimes a squinky hack is the cleanest solution, and in
some cases the trusted developer has looked at the other alternatives,
and it really is the best solution, and in other solutions, the
untrusted developer has to advance every single alternative, get them
all NACK'ed, until someone suggests his original approach, at which
point the untrusted developer explains in frustration, "I had
suggested that already --- five months ago!!!"

2.)  The user/consumer who either is, or has has direct access to,
someone who is a competent Linux kernel developer, but who is not
trusted as a "core" kernel developer.  This is someone who really does
have to socialize his/her ideas through the LKML, precisely because he
or she doesn't have the trust of the community that his/her ideas are
sane, and that the developer doesn't fall into class #3 below.
Sometimes if he/she can get a "core" kernel community member to either
sponsor the patch series, or to pull it into one of the "core"
member's git trees, the process of getting the patches vetted can get
short circuited; but of course, the "core" member had better be pretty
convinced that the patches are clean and the design is the best and
most general possible given the engineering constraints at hand.

3.)  The user/consumer who either is, or has direct access to, someone
who may or may not be a competent kernel coder, but who has patently
bad design taste.  The design might not be totally insane; for example
there are plenty of well respected academics, including Prof. Andrew
S. Tanenbaum, who are still pushing microkernels.  Or it might have
made sense in the context if Windows, which runs all sorts of
anti-virus code in kernel context; but it is clearly not the dominant
design paradigm for Linux.  The "socratic method" of reviewing
patches, which can often be quite brutal for patches coming from
unknown sources, is primarily designed to weed out people which fall
in this category.  To many kernel developers, the most scary
ideas/patches are not the ones which are totally outlandish and crazy
(such as making the kernel be able to parse and execute SQL-like
statements as arguments to a modified readdir system call, in the
grand but quixotic goal of unifying filesystems and databases), but
the ones which are just sane enough to be initially appealing, but
which ends up being a millstone making future development and
backwards compatibility efforts extremely difficult.  At least, this
is the fear which I suspect drives the often harsh reception some have
received (regardless of whether that reception was justified or not).

4.)  The user/consumer who does not have access to any kind of kernel
developer at all, but has some idea/need that they wish someone will
code for them for free.  Unlike the first three cases, this person
must approach the kernel community (either via LKML or some other
path) without a patch in hand, but only a plea to do some coding work.
This class can be subdivided into two cases:

   4a).  There is an active kernel developer in the area of the kernel
   involved, and the user/consumer can clearly articulate (perhaps
   with the help if the kernel developer) the characteristics of
   his/her workload that needs performance tuning, or the whys and
   wherefores of the feature that he/she needed.  If it's small
   enough, the kernel developer may very well do it "for free", or the
   developer may say, "yeah it's a good idea, but I don't have the
   time to do it; here's the rough design if someone wants to step up
   and do it, though."

  4b.)  There is no active kernel developer in that part of the
  kernel, and/or the user/consumer isn't capable of articulating the
  design requirements cleanly enough that it could be delegated to a
  particular kernel developer --- or maybe the user/consumer can't
  even explain the idea clearly enough so people can decide whether or
  not he/she has a valid request, or is a crackpot.

The reason why I like this taxonomy is I think it helps explain why
certain ideas/request for implementations/patches get treated the way
that they do, and if people understand this, then perhaps they'll
understand that if they get treated a certain way, it's not because
people are mean-spirited or malicious, but because we get these are
the natural mechanisms which have evolved over time to filter out bad
designs, bad code, and crackpots.  

I think it might also suggest ways that they might be able to reach
out to various community members one-on-one, perhaps at a conference,
or perhaps as a paid consultant (for those who don't already have
full-time jobs at some Linux company), or perhaps via e-mail asking
for some help and suggestions about how to push some idea, in a way
that's productive and less frustrating for all concerned.

						- Ted