Subject: Re: got drivers?
To: None <email@example.com>
From: Seth Kurtzberg <firstname.lastname@example.org>
Date: 01/24/2005 17:53:48
It would certainly be interesting to develop a device driver interface
layer that allows drivers from other operating systems to become virtual
NetBSD drivers. In principle this shouldn't be difficult, but this is
certainly one of those instances where the devil would be in the
details. (If there is already something of this sort in the works, and
I missed it, then my apologies; I did check the list archives but that
is not to say I didn't miss something.)
My view is that, if something like this is to be attempted, it should be
part of a general capability which allows the addition of libraries that
act like "plug-ins" for a given O/S device driver interface. The place
to start (again IMO) is an analysis and comparison of the currently
available open source device driver interfaces; Dieter's list
(Free/OpenBSD, and Linux) should certainly be part of this. If there
are others that should be considered in such an effort, I'm sure people
on the list will provide that information.
I have a reasonably good working knowledge of the device driver
interface for Linux and for NetBSD, so I'd be willing to be part of an
effort to design a workable abstraction layer which would define the
requirements for a "plug-in". (I'm using the quotes around plug-in
because the mechanism would be quite different, and I'm just sketching
out a very high level suggestion which may turn out to be flawed.)
That's assuming, of course, that there is a consensus that such an
effort would be valuable. It should be considered that such a
capability has the potential to reduce NetBSD stability, because the
quality of device drivers (in Linux particularly) varies from very good
to almost useless. Even if NetBSD were to designate specific drivers as
stable, nothing would stop users from using other, less stable drivers.
As I'm sure nobody wants to encourage something that might reflect badly
on NetBSD as a whole, the stability issue should be carefully considered.
One thing that might make this less risky is that my non-technical
business type users think the NetBSD machines are Linux machines. So
they might just get the impression in Linux is not stable. :)
You could build into an abstraction layer of this type either a fixed
(updatable) list of allowable drivers, or you could have a site with a
dynamic list of acceptable drivers that the abstraction layer consults
before allowing a driver to be used. This sounds good, but it means
that somebody (or somebodies) would have to spend significant amounts of
time judging the stability of drivers, which means of course that they
probably need to have the hardware associated with the driver.
It also won't do to just go by the version number and the driver
classification assigned by the other operating system (new,
experimental, stable, etc.) I'm running a pre-release version of
drivers for Atheros 802.11g hardware, that is working perfectly although
its revision is < 0.5. Other drivers with revision numbers indicating
that they are stable and released are, in fact, not stable (ATI drivers,
Anyway, comments on the merit and practicality of such a thing will be
>Having used NetBSD for many years now, the biggest problem I see
>with NetBSD is device drivers.
>Can't talk to this device, no driver. Can't talk to that device,
>Even if there is a driver it is frequently buggy. About the only thing
>that works reliably is SCSI. Even a common ATA disk creates problems
>for seemingly unrelated devices.
>What would it take to create an interface that allowed linking
>in drivers from FreeBSD/OpenBSD/Linux/... ?