|From:||James Bottomley <James.Bottomley-AT-HansenPartnership.com>|
|To:||Jonathan Corbet <corbet-AT-lwn.net>|
|Subject:||Re: [Ksummit-2009-discuss] Meeting userspace requirements|
|Date:||Sat, 11 Jul 2009 18:54:18 -0500|
On Sat, 2009-07-11 at 17:34 -0600, Jonathan Corbet wrote: > On Sat, 11 Jul 2009 11:30:02 -0500 > James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > Maybe. What exactly is the problem ? They know where firstname.lastname@example.org is, > > > so why aren't they talking to us there ? > > > > Yes, this would be my first question too ... is it because lkml is too > > intimidating? > > "Well, this is open source ... you don't get to request new > features; you get to implement them" > > -- James Bottomley, September 2009 > http://lkml.org/lkml/2008/9/26/206 Slight elasticity of context here: I was saying that to a writer of a new driver who had previously expressed surprise that they could propose patches to the core kernel (or in this case the transport classes) to support what they wanted to do instead of either having to make a feature request or simply implement it in their driver. > I think that linux-kernel is seen as a relatively unfriendly place for > people who just want to request something. The fact that some people > come in with demands doesn't help, certainly, but even people who try to > clearly express real needs can often look forward to "patches welcome" > as the best possible response. OK, so looking at the above I think there are three classes of people requesting features 1. Like the above ... sophisticated consumer, capable of writing their own code, just didn't realise that they could code a feature and submit it (mainly because no other OS does this, even if you get access to the source code under NDA) 2. Users who can interest general developers in their feature ... usually either because it's a neat, cool extension of something the developer has done before or because it takes the developer's code into situations the developer can't test themselves. 3. Users who have esoteric feature requests that no general developer would be interested in. (Like I've got this XYZ data capture card and I won't use Linux unless you write a driver for it). I think cases one and two can be handled by documentation and outreach. It's case three I'm a bit troubled by. When the same request comes into a proprietary OS, they either say "sure, that will be $x thousands of dollars, please" or "well, you're the first person to ask, prove to us (by finding others who need this) that there's a business case for this feature". We don't really have any equivalent mechanisms (well, other than "why don't you find a group of people who need this and fund a developer to work on it?"). > "How can users and user-space developers communicate their needs to the > kernel community?" seems to me like a good topic to discuss. A > document seems like a good start; maybe I can even help on that front. > But I bet there would be value in talking about the question and not > just expecting Yet Another Document to fix things by itself. Certainly; I can help with this too ... we could run it immediately after the end user panel (hopefully we'll have some real world issues coming out of that). James
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds