public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 23:02:20 -0500	[thread overview]
Message-ID: <20060208040220.GC7394@thunk.org> (raw)
In-Reply-To: <43E940BF.7020203@shaolinmicro.com>

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 propietary 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 propietary, 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 propietary 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.

  reply	other threads:[~2006-02-08  4:02 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
2006-02-08  0:52       ` David Chow
2006-02-08  4:02         ` Theodore Ts'o [this message]
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=20060208040220.GC7394@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