Re: [Q]: Linux and real device drivers

David Weinehall (tao@acc.umu.se)
Mon, 27 Sep 1999 12:45:16 +0200 (MET_DST)


On Mon, 27 Sep 1999 tytso@mit.edu wrote:

> Date: Fri, 24 Sep 1999 23:14:15 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> Which is harder
>
> 'Bananavision capture card ?'
> type N
>
> or
>
> 'How do I search the web for a foo1500 scsi controller. Has anyone tested
> this driver with 2.2.11.....
>
> Which is harder?
>
> User buys Banavision capture card. Oops! Not supported in 2.2. User
> has to wait for the 2.4 kernel to come out (months and months
> away).... or use a development kernel. Whoops! 2.3 kernel has
> incompatible changes requiring user to update user mode programs....
>
> Or... Banavision capture card comes with diskette or CD-ROM containing
> an RPM file which the user simply has to install using RPM -i. As part
> of the RPM install, the post-install script automatically recompiles the
> driver to match the kernel the user has installed, and it just works.
> User can also download from Banavision.com's web page the latest RPM
> that works with 2.2.11.....

Or... Banavision sends their driver to Alan Cox who maintains the stable
kernels, and Alan promptly releases kernel vX.Y.Z+1 in the course of a
week or two, and thus the driver might even be out before the hardware
hits the shelves in the computer-store...

And of course. I see a great danger with it otherwise; the vendor of
Banavision spreads an RPM on their CD's, because Red Hat is the most
common distribution. Users of other distributions can't install it...
(Sure, it's no problem if you know how to convert the packages, but I can
tell you, that a Debian-user like me doesn't exactly become excuberantly
happy by the fact that much software is only release in RPM's nowadays...

> The reason why Windows is easier in these sorts of situations is that
> it is up to the hardware vendors to supply the device driver. Linux is
> becoming popular enough that some vendors are going to be willing to
> supply a Linux driver; but there needs to be an easy way for them to get
> a driver installed on a user's machine. They can't wait for RedHat to
> spin a new CD-ROM, or for Linus to stablize the development series, or
> even for Alan Cox to put out a new 2.2 kernel (and even then most users
> may not be able to deal with a 2.2 kernel; they may have to wait for a
> distribution to get around to including the latest stable kernel).

Sure. But we also know how many drivers in Windows that have subtle bugs
because the hardware manufactors haven't understood the API fully. If the
driver gets into the kernel, it has a larger chance of getting a code
review even by people that doesn't even own such a beast...

> As Linux becomes more successful, and as we start attracting more users
> which aren't kernel developers, the same old ways that we've used in the
> past might, just **possibly**, not be the ones that will work the best
> in the new world order. Or should we just tell the naive users that so
> sorry, they can't use the banavision capture card under Linux just yet,
> come back in 6 months, and in the meantime, use Windows 2000 (since the
> Banavision CD-ROM came with installable Windows drivers)?

No, we tell them to upgrade their kernel, as kernel vX.Y.Z, which was
released half a year ago at the same time Banavision released their
adapter, supports that very hardware. After all, if the
hardware-manufactors makes a driver, they can as well submit it to
Linus, with the added bonus that there's a quite large potential of
getting bugs fixed.

> I hope not! That's downright embarassing.

Sure, but it's more embarassing to get into the situation Microsoft has
with an API that never is obsoleted, because someone might still run old
drivers...

/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/