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

That's *daemon* in the details.  :-)

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

You could add DragonflyBSD.  Maybe Solaris, they are supposedly
becoming some form of open source.  Maybe Apple's OS X, although
I wonder if there are or will be any open source OS X drivers.

It appears that the popular platforms at the moment are wintel,
Linux/x86 and OS X.  Therefore they are the platforms most
likely to have drivers we might want.  Note that I haven't
suggested adding ms virus server to the list.

> That's assuming, of course, that there is a consensus that such an 
> effort would be valuable.

In addition to being valuable to those of us currently running NetBSD,
adding significant new capabilities, it would help change the perception
of NetBSD.  Currently the view seems to be "Yeah NetBSD runs on anything
with more computing power than a light bulb, but in many cases all that
means is you can get a login prompt, and there is poor driver support.
NetBSD is something to run on old, oddball hardware, shoved into a corner
of the server room."  I'm not sure what the just-a-login-prompt thing is
all about, but the rest of it has a lot of truth to it.  :-(

And someone (not me) could get a Usenix paper out of it.  :-)

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

I think the sort of people running NetBSD are bright enough to not
blame NetBSD for problems caused by 3rd party software.  I've found
some pkgs to be completely useless (non-functional) but I don't
see anyone blaming NetBSD for bad pkgs.

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

I'm thinking that this is a bit more than we need.  I'd suggest a web page
with a list of drivers that people have tried, and the results they got.
	"Works great, fast, no problems."
	"Works, but uses lots of CPU."
	"Sorta works, but kinda flaky.  Needs work."
	"Works, except for the FOO feature."
	"Works but throughput is terrible."
	"Panics the OS.  Not recommended."

A similar list for hardware (Ethernet cards, video cards, disks, whatever)
would be very useful as well.  By make and model, as it may not be easy to
detirmine what chip a product uses.  And there more to a card than just the
biggest chip.