|| ||James Bottomley <James.Bottomley-AT-HansenPartnership.com> |
|| ||Jonathan Corbet <corbet-AT-lwn.net> |
|| ||Re: [Ksummit-2009-discuss] Meeting userspace requirements |
|| ||Sat, 11 Jul 2009 18:54:18 -0500|
|| ||Article, Thread
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 email@example.com 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
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
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
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
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).
to post comments)