From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: David Chow <davidchow@shaolinmicro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux drivers management
Date: Wed, 08 Feb 2006 01:06:03 +0000 [thread overview]
Message-ID: <1139360763.22595.10.camel@localhost.localdomain> (raw)
In-Reply-To: <43E8F8EB.8010800@shaolinmicro.com>
On Mer, 2006-02-08 at 03:45 +0800, David Chow wrote:
> Community Developers and Maintainers:
> - Look at the matter on community development process, programming
> - Chase for performance, optimization in source level, even though it is
> difficult to maintain, who cares?
I've done real studies on this. The majority of the kernel interfaces
favour simplicity and independance.
> - Willing to maintain and develop drivers for free, even though they
> don't work for the hardware vendor.
Most of our drivers are maintained by people with economic incentives to
maintain them. Economic incentives are not always cash and employment.
> - We will follow the convention who make changes to the API will have to
> patch all the mess in the kernel source, even though there are 3,714,234
> hardware peripheral drivers in the kernel in year 2012, I am happy to do
> that :) . Because I want to make change and following the convention.
> (how much time to make change or test?)
I'd beg to differ. The amount of hardware interfaces in a system that
are non standard has been dropping like a stone. Software is *expensive*
and it is getting cheaper and cheaper for commodity products to adopt a
commodity API, especially in the open source world where pure software
pricing scams (eg extra cost for flipping the 'raid enable' bit on a
controller) don't work.
The recent directions are pretty clear
IDE -> Various interfaces -> AHCI
A billion periphals -> USB (EHCI/OHCI/UHCI) + Class drivers
SATA -> AHCI
Sound -> Intel i810 clones/AC97
USB imaging random drivers -> USB video classes
Scanners -> USB video/image classes
A billion camera interfaces -> USB storage
A load of MP3 player interfaces -> USB storage
Its getting harder and harder to justify non-standard APIs except in a
few areas like infinibong and 3D graphics where they can make a product
genuinely better. Even RAID cards are drifting inexorably to either
extinction or emulating standard interfaces, and no doubt will
eventually end up AHCI.
> the community. But strictly speaking, it shouldn't. Please refer to the
> process of making a driver from a manufacturers point of view and
> consider user using old OS'es which don't want to upgrade.
But those people have a stable API - usually RHEL3, RHEL4, SuSE
Enterprise.
> Sure its not going to change, maybe but not in a year or two, but
> freedom of speech exists, right?
Time will tell. People said the same when Linux got so big it wouldn't
fit on one floppy disk. I can't prove you are wrong but my suspicion is
that economic incentives and pressures will mould the development
process over time according to the problems it faces.
Alan
next prev parent reply other threads:[~2006-02-08 1:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-07 4:42 linux
2006-02-07 16:18 ` Eric W. Biederman
2006-02-07 19:45 ` David Chow
2006-02-07 20:03 ` Kyle Moffett
2006-02-07 22:15 ` Theodore Ts'o
2006-02-08 0:52 ` David Chow
2006-02-08 4:02 ` Theodore Ts'o
2006-02-08 9:46 ` Bernd Petrovitsch
2006-02-09 6:09 ` Lee Revell
2006-02-08 1:06 ` Alan Cox [this message]
2006-02-08 8:26 ` Denis Vlasenko
2006-02-11 18:47 ` Andrew James Wade
-- strict thread matches above, loose matches on Subject: below --
2006-02-06 19:30 Nicolas Mailhot
2006-02-06 18:31 Nicolas Mailhot
2006-02-06 18:56 ` Yaroslav Rastrigin
2006-02-06 19:02 ` Joshua Kugler
2006-02-06 19:17 ` Yaroslav Rastrigin
2006-02-06 19:39 ` Martin Mares
2006-02-06 19:56 ` Jan-Benedict Glaw
2006-02-06 19:53 ` Jan-Benedict Glaw
2006-02-06 20:04 ` Jesper Juhl
2006-02-06 23:52 ` Bernd Petrovitsch
2006-02-06 19:21 ` linux-os (Dick Johnson)
2006-02-06 19:46 ` Michael Krufky
2006-02-06 19:58 ` Nicolas Mailhot
2006-02-06 23:16 ` Gene Heskett
2006-02-06 9:45 David Chow
2006-02-06 10:05 ` Michal Schmidt
2006-02-06 16:50 ` David Chow
2006-02-06 16:55 ` Randy.Dunlap
2006-02-06 19:45 ` Alan Cox
2006-02-06 19:46 ` Jesper Juhl
2006-02-06 10:08 ` Jes Sorensen
2006-02-06 16:52 ` David Chow
2006-02-06 17:03 ` Pedro Alves
2006-02-06 17:35 ` Geert Uytterhoeven
2006-02-06 17:42 ` Jes Sorensen
2006-02-06 16:56 ` Christoph Hellwig
2006-02-07 11:36 ` Denis Vlasenko
2006-02-07 13:22 ` Christoph Hellwig
2006-02-06 19:51 ` Greg KH
2006-02-06 21:38 ` Jim Crilly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1139360763.22595.10.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=davidchow@shaolinmicro.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®