Re: got drivers?

Dieter wrote:

>>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.
>  
>
That's probably a simpler and better idea than mine, certainly for an 
initial cut.

I take your point about packages.

The Solaris device driver interface (really, all System V device driver 
interfaces) have two classes of driver: ordinary and streams.  (Ordinary 
is the wrong word but I hope the meaning is clear.)  Interfacing to a 
streams driver would be non-trivial.  Of course, if sun never opens the 
driver source the issue is moot, so it is safe to ignore it for now.

Are there OSX drivers that are not available in the Darwin source code 
that are open source?

In discussing stability I was thinking more about end users.  Rethinking 
that issue, stability wouldn't be a big issue if the capability were 
disabled by default and enabling it requires more technical savvy than a 
bozo would have.

I'm going to take a crack at a very high level design and estimation of 
the scope and logistics that might be involved.  Then we can have a more 
valuable discussion as to the practicality of the idea.

Seth

>!DSPAM:41f5f2a1104231881510136!
>
>  
>