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, 
for example).

Anyway, comments on the merit and practicality of such a thing will be 
interesting.

Seth Kurtzberg
seth@cql.com

Dieter wrote:

>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,
>no driver.
>
>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/... ?
>
>!DSPAM:41f15891193137884015205!
>
>  
>