From: "Theodore Ts'o" <tytso@mit.edu>
To: David Chow <davidchow@shaolinmicro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux drivers management
Date: Tue, 7 Feb 2006 17:15:13 -0500 [thread overview]
Message-ID: <20060207221513.GA7394@thunk.org> (raw)
In-Reply-To: <43E8F8EB.8010800@shaolinmicro.com>
On Wed, Feb 08, 2006 at 03:45:47AM +0800, David Chow wrote:
> - What is the goal of Linux developers? Just for fun? Or you want Linux
> to get more popular? Users want their system to get supported with
> latest drivers, not to compile and build to latest kernel. Or not to
> upgrade their Linux distro every week or month. I don't use 2.6.15 nor
> happy downloading 40Mb targged gzip kernel source and knowing how to
> "make" it.
Every Linux developer has their own goals, of course, but for most of
them it is about making the best possible Linux kernel that is
technically possible. If they have working drivers for their system,
they may not necessarily care about some company's hardware unless,
(a) it impacts them personally, (b) they are paid or employed to worry
about it, or (c) lots of end-users are sending complaining/sending
hate-mail about it.
(In some cases, end-users send hate mail to the Linux kernel
developers when some idiot company's binary driver modules is buggy
and corrupts the kernel in hard-to-debug ways; one particular video
driver company is especially guilty here, and is viewed by some as
being directly responsible for the tainted kernel flags.)
The assumption by many developers is that if we concetrate on making
Linux as good as possible, it will eventually get popular enough that
hardware vendors will feel a commercial incentive to cooperate with
our way of doing things. Obviously, this in practice things don't
always work that way --- the Sony Betamax is story is one where
technical excellence doesn't always win out. However, at least in the
server space, compromising hasn't obviously been a bad strategy, with
many SCSI and FC controller manufacturers deciding on their own to
work with the Linux kernel development community. (Sometimes with
some help from major system vendors who write in a requirement for a
mainline device driver into the sourcing contracts for said
controllers, but nevertheless, it shows that this stance is not
obviously a bad strategy for Linux kernel developers, at least in the
server space.)
David, you may find this frustrating, and at least in the Deskstop
space, it's likely that your company hasn't seen sourcing contracts
yet where a mainline acceptable device driver is a requirement for
some major system vendor, like Dell, Gateway, HP, etc. to decide to
use your products. I suspect that if this _was_ the case, your
company would in fact dedicate the full-time engineer necessary to
make a device driver which could be integrated into the mainstream
kernel sources and then could be backported to older distributions.
But if you did, I think it is certainly doable.
But at that point it stops being a technical question of "is it
possible" and moves to an economic question of "are we willing to fund
a full-time engineer to provide support for our hardware under Linux"
and "how popular does the Linux desktop have to be before a system
vendor will feel obliged to put pressure on their downstream suppliers
to provide the necessary driver support"? And as such, LKML will
probably not be a very useful place to have that discussion.
Regards,
- Ted
next prev parent reply other threads:[~2006-02-07 22:15 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-07 4:42 Linux drivers management 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 [this message]
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
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=20060207221513.GA7394@thunk.org \
--to=tytso@mit.edu \
--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