From: Theodore Ts'o <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Linux drivers management
Date: Wed, 08 Feb 2006 04:02:51 UTC
Message-ID: <fa.8FIz6BFrRV2FuaexKP0sdL6e2Gg@ifi.uio.no>
Original-Message-ID: <20060208040220.GC7394@thunk.org>

On Wed, Feb 08, 2006 at 08:52:15AM +0800, David Chow wrote:
> I have no expectation the LKML will agree to my point . Because 99% of
> the LKML are likely technical users and community developers. As said,
> they only care about programming drivers in the kernel source. Freedom
> of change is cool and fun for them.

Actually, most of the developers work for some a distributions or a
system vendor.  I for example happen to work for IBM's Linux
Technology Center.  In that role, I do worry about the device drivers
for the hardware devices that we sell to our customers.  However, I
also am a community developer, and with that hat on I care about Linux
being the best OS it can be technically.

I will say that my experience has been that binary kernel modules can
easily turn into a disaster for our customers.  It's a major issue
when a customer needs to install an errata kernel issued by one of our
Linux Distribution Partners for stability or security reasons, and
they are using a proprietary binary kernel module from some third party
storage vendor which hasn't yet updated their proprietary binary
driver for that errata kernel.

Or there was the time that positively warmed my heart when I spent
several very late nights trying to debug a situation for a very high
profile, important customer trying to use a Samba file server running
on IBM hardware being integrated by IBM Global Services, and the
system kept on falling over.  It turned out the problem was caused by
a memory leak in a proprietary, binary-only kernel module from an
commercial anti-virus product that shall remain nameless.

So I am firm believer in giving our customers access to source code to
all kernel code, not because of any deep desire to "programming
drivers in kernel source", or because of any "information wants to be
free" religion --- but because it's the best way to keep our
customer's systems running reliably and nearly problem-free --- and
when there is a problem, I know that we have whatever is necessary to
make their problem Go Away.

Yes, I'm aware of the traditional arguments that a stable device
driver API would solve all of these problems.  Well.... at least the
first problem; incompetently written proprietary kernel modules filled
with memory leaks and wild pointer dereferences and race conditions
aren't solved by standardized driver API's; the only solution is
source access so we can fix the idiotically written modules.  But the
reality is the way the Linux kernel is developed, a stable driver API
would never work.

						- Ted

P.S.  Obligatory disclaimer: These are my own opinions, and not
necessarily those of my employer.

From: Theodore Ts'o <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Linux drivers management
Date: Tue, 07 Feb 2006 22:15:56 UTC
Message-ID: <fa.Cw0agslvWZNhOfAjcflD4xgHVXI@ifi.uio.no>
Original-Message-ID: <20060207221513.GA7394@thunk.org>

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