|From:||Theodore Tso <tytso-AT-mit.edu>|
|To:||James Bottomley <James.Bottomley-AT-HansenPartnership.com>|
|Subject:||Re: [Ksummit-2009-discuss] Meeting userspace requirements|
|Date:||Sun, 12 Jul 2009 07:29:43 -0400|
|Cc:||Jonathan Corbet <corbet-AT-lwn.net>, ksummit-2009-discuss-AT-lists.linux-foundation.org|
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
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds