Linux Driver Project Status Report as of April 2008
onetwojojo at gmail.com
Tue Apr 8 00:44:51 PDT 2008
On Tue, Apr 8, 2008 at 12:12 PM, Greg KH <greg at kroah.com> wrote:
> Exactly, it's not a simple "oh look, these drivers came exactly from our
> efforts" type of thing. The reach and range of this effort is already
> quite large, trying to quantify it for no good reason isn't something
> that I'm going to worry about.
> In the end, what would it really achieve?
This is where the project management function is failing,
if you can't quantify the progress made (or lack thereof),
you can't take proper corrective action for strategy.
(ex. Last year we wrote 10 drivers, this year we will write 11 drivers,
now if we say there are 1000 drivers yet to be written, then clearly
the current strategy needs rework, this decision can only be based
indication of progress made, on the other hand if there are only 14
drivers yet to be written,
then the current strategy is fine, write 11 drivers this year.)
....or do you rather prefer walmart releasing their annual report as
"oh we made some profit this year."
> > b) You need to segregate the LDP targets into 2 categories
> > Enterprise endusers & Non-Enterprise endusers.
> I do not believe in those two categories at all.
well I do,
"Enterprise endusers" will quickly find their latest storage(SAN etc)
h/w linux drivers,
getting improved all the time, with the vendor paying for it directly
"Non-Enterprise endusers" will always find their gadget, not working,
not working correctly,
not full featured.
the above is a typical classification of h/w & support level, and is
very applicable to all h/w
> That's not true, there is lots of money made every day in the
> "non-enterprise" markets. Think consumer, embedded, phones, etc.
- the probability of making money(amount of money) by writing drivers in
"Enterprise enduser" market > "Non-Enterprise enduser" market
- & the difference in probability of the two above is probably more
than 0.8 ;-)
> The goal is "drivers for all devices from any manufacturer that wants
> them." We do not descriminate by market share or anything else.
Manufacturers will do the bare minimum required, needed to make them money,
(usually referred to as cost-benefit analysis).
Are you saying that an enduser, should not expect to be able to use
the h/w how he wants to
but only instead as manufacturer intended ? (vendor lock-in?)
if manufacturers want to provide the enduser with Linux drivers its fine,
if he does not provide linux drivers, the enduser should not use the
h/w with Linux ?
Manufacturers usually show this level of concern (we need linux
drivers of our h/w),
only for their big customers (read "enterprise endusers").
> "war"? This isn't a "us vs. them" type thing at all, despite the human
> nature of always wanting to create such a story to explain things.
just a term to signify the urgency of a tangible longterm solution.
> > Please work to centralize the H/W compatibility list, every distro is
> > rolling their own...its all a mess
> That is outside the scope of our effort, sorry.
Then the scope needs to be corrected for this project to succeed doesn't it ?
(or is the scope set in stone ?, disregarding the ground realities)
> > Start a major effort to Whitelist/Blacklist Manufacturer & Devices,
> > the Idea is as below
> > - Centralize h/w compatibility support list
> > - This list will have regularly updated list of _actual_ Brand Names
> > & model numbers
> > - Users will use this before buying h/w (you wish !!)
> > - Users will report incompatibility too.
> > - Start rating Manufacturer based on its support for FSF/openness
> > - Users must reward the more open Manufacturer based on this list by
> > spending their money.(wishlist)
> > - this is based on the carrot & stick approach, your strategy only
> > uses the carrot approach,
> > (MicroSoft uses both carrot & stick, by funding you or your competitors.)
> Such a list will always fail in the end, there is no possible way to
> keep up with it properly due to the vastness of the computer market in
> the whole world. People have tried in the past, and always failed.
Thats why I asked to involve endusers in your strategy, they are the
source of this info,
and they can keep it.
> I wish those who want to try again the best of luck, but it's not
> something that I ever wish to do. We are working on code and education
> to create more code, not white/black lists.
Sometimes, its certainly possible, what you want to do and what needs
to be done are different things.
> > d) is LDP for the benefit of all endusers, or just the enterprise ones ?
> > (just making sure this is discussed/answered)
> See above.
again pressing for answers
> > e) reverse-engineering is _THE_ opensource way, (going back to the
> > time of PDP ?)
> > do you agree to the above statement, as a spokesmen for Linux as a OS?
> I am a spokesman for no one but myself, and that statement doesn't make
> any sense to me at all.
well Novel recognizing your efforts, and hiring you to continue the good work,
makes you a representative of sorts, that knows whats good for the community.
(most of the early FSF utilities started with reverse engineering,
& they kept up reversing all new features of the closed source ones,
thats what I was referring to)
> > f) putting 2+2 together,
> > - If you care about doing something to help all end users (not just
> > enterprise ones)
> > - reverse-engineering is _the_ opensource way
> > wouldn't it make more sense to mobilize your efforts to solve this
> > pressing problem,
> > with / without documentation being made available ?
> No. :)
> > g) there's a reason manufacturers don't bother with documentation,
> > they make a IC in a batch, and if they only have order for 1 batch
> > run, why bother with documentation,
> > just fab it and forget about it, is their attitude.
> That is not true, having worked with many manufacturers in the past and
Well thats the answer I got from a manufacturer I contacted,
so yes that is True. (and I am not just hand waving in the air here ;-0)
> > e) wireless is a mess because of FCC regulations, they want
> > manufacturers to limit the operating capabilities of the
> > device(frequencies), manufacturers figure that its cheaper to do this
> > in s/w rather than h/w, by making a closed source firmware. I don't
> > see how we can improve this situation unless you can help EU legislate
> > it away (assuming US is a lost cause)
> The whole FCC thing is, in my personal opinion, a big excuse that some
> companies are using to not release the code for their hardware. If you
> notice, other companies do not believe this and have released code.
Some of the concerns are valid, and yes the companies use this to
circumvent publishing the specs.
(leading to vendor lockin)
> Either way, the very capable, and active developers of the
> linux-wireless projects are working to resolve all of the wireless
> driver issues. If you have questions or concerns about these types of
> devices, please contact them.
the linux-wireless developers are still sticking to NDIS wrapper
approach, (well some of them are ;-)
Even if you didn't want them to use those GPL symbols, they still
continue, they have no choice.
Another possible strategy I would suggest, is to increase the number
of Linux driver developers 3 fold,
an increase like that would have appreciable effect on demand on Linux
> greg k-h
More information about the devel