public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: erich@uruk.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: Loadable drivers  [was  SMP/cc Cluster description ]
Date: 05 Dec 2001 21:44:06 +0100	[thread overview]
Message-ID: <p738zch8kix.fsf@amdsim2.suse.de> (raw)
In-Reply-To: <E16BY3e-0005S9-00@the-village.bc.nu.suse.lists.linux.kernel> <E16Bhtn-0004xf-00@trillium-hollow.org.suse.lists.linux.kernel>
In-Reply-To: erich@uruk.org's message of "5 Dec 2001 20:43:05 +0100"

erich@uruk.org writes:
> 
> MS with Windows (and even DOS) went the right direction here.  In fact,
> they have been hurting themselves by what lack of driver interoperability
> there is even between Windows NT/2K/XP.  Admittedly they didn't have much
> of a choice with their closed-source scheme, but it still is a better
> solution from a usability and stability point of view in general.

I remember some quote from a Microsoft manager when they released Win2k.
(paraphrased) "A significant percentage of the blue screens in NT4 were 
caused by buggy third party drivers." (and then how they will try to avoid
it in the future by having more stringent windows logo tests etc.

The experience in recemt Linux is basically similar. Single Linux has
gained vendor support in drivers it has gotten a lot more unstable
than it used to be (sad but true). There are first a lot more and more
complex drivers than there used to be.  A lot of drivers both writen
by individuals and also companies for their are simply crappy buggy
code. I could give you numerous examples here; names withheld to
protect the guilty. For hardware companies it might be because driver
writing is not a profit center, but a cost. There might be other
reasons. There are just a lot of bad drivers around.

[This is not a general insult on driver writers; there are some very well
written drivers, but also unfortunately a lot of bad ones.]

Now when a driver crashes guess who is blamed? Not the driver author
but the Linux kernel is seen as unstable and it effectively is as 
a end result - it doesn't work for the user. All just because of bad drivers. 

The solution that is tried in Linux land to avoid the "buggy drivers" ->
"linux going to windows levels of stability" trap is to keep drivers in tree
and aggressively auditing them; trying to fix their bugs.

A lot of driver code is actually cut'n'pasted or based
on other driver code (or you can say they often use common design patterns)
Now when a bug/race/.. is found and fixed in one driver having the majority
of drivers in tree makes it actually possible to fix the bug who is likely
in other drivers who use similar code there too. With having drivers in external
trees that crashing/angry user/debugging/etc. would likely need to be done once 
per driver; overall causing much more pain for everybody. 

Your scheme would make this strategy of tight quality control of
drivers much harder, and I think it wouldn't do good to the long term
stability of linux.

There are other reasons why linux has really no stable driver interface.
Sometimes it is just needed to break drivers to fix some bugs cleanly.
Getting rid of this possibility (fixing bugs cleanly even if it requires
changes in other kernel code) would also cause more bugs in the long term.

-Andi


       reply	other threads:[~2001-12-05 20:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E16BY3e-0005S9-00@the-village.bc.nu.suse.lists.linux.kernel>
     [not found] ` <E16Bhtn-0004xf-00@trillium-hollow.org.suse.lists.linux.kernel>
2001-12-05 20:44   ` Andi Kleen [this message]
2001-12-05 21:52     ` Loadable drivers [was SMP/cc Cluster description ] erich
2001-12-05 23:56     ` Alan Cox
2001-12-05  9:09 SMP/cc Cluster description [was Linux/Pro] Alan Cox
2001-12-05 19:40 ` Loadable drivers [was SMP/cc Cluster description ] erich
2001-12-05 20:04   ` erich
2001-12-05 20:28   ` Stephan von Krawczynski
2001-12-05 21:17     ` erich
2001-12-06 16:34       ` Stephan von Krawczynski
2001-12-06 20:14         ` Kai Henningsen
2001-12-07  0:37         ` erich
2001-12-07 13:34           ` Stephan von Krawczynski
2001-12-06  4:49   ` Keith Owens
2001-12-07  0:41     ` erich

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=p738zch8kix.fsf@amdsim2.suse.de \
    --to=ak@suse.de \
    --cc=erich@uruk.org \
    --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