Subject: Re: Uniform Driver Interface proposal
To: Johan Ihren <johani@autonomica.se>
From: Henry Miller <hank@black-hole.com>
List: tech-kern
Date: 04/12/2001 17:52:12
On 12 Apr 2001, Johan Ihren wrote:

> Jason R Thorpe <thorpej@zembu.com> writes:
> 
> > On Wed, Apr 11, 2001 at 11:08:41PM -0700, Greywolf wrote:
> > 
> >> Begging pardon, but doesn't every layer you shove in there as an
> >> abstraction cost performance?  We already endure that price for our
> >> cross-platform portability.
> > 
> > There's nothing wrong with having an (optional) UDI shim layer, in
> > case there are binary drivers that you just HAVE to have... but yes,
> > native drivers are always better.
> 
> Would it be possible to build such a shim layer that provides the API
> expected by windoze drivers? I.e. so that it would be possible to use
> the (today useless) stuff on the CD/floppy/vendor website/whatever
> that accompanies the device while waiting for native support?
> 
> I realize that the windoze API is probably neither small, elegant or
> easy to provide from Unix, but is it *possible*?
> 
> If it was I think that would be really useful, since it would provide
> access to drivers for mostly everything that are already written, some
> of which cannot easily be natively implemented due to lack of
> documentation.

Anything is possibal in theory.  However it isn't easy.  before you start
you need to ask what you really want.  What are you trying to run that
isn't documentated?

Many of the answers will be something like "This dirt cheap FM radio
card".  In that case you don't just want the driver, you also want the
user interface to make it work.   So you really are looking tieing wine
into the kernel so it can directly access hardware.   (Many devices on
this level are VxDs, and rely on applications having direct hardware
acceess) I don't think I need to elaberate on why that is a bad
idea. 

If the answer is "a new SCSI controller", there is a much better chance
that it can be made to work, but still hard.   Might be worth having, if
you can get all the mappings to work out.   

Devices in the first catagory generally don't work with windows NT, so if
your just trying for the latter make sure it will work with NT.  NT works
more like unix then regular windows, and if there are differences in the
drivers (I belive they are generally compatable) you will find it easier
to support the NT drivers.  

If you have the time, go for it.  However don't expect that one day netBSD
will prefer windows drivers.  Just like with UDI, native drivers tend to
be just enough faster that they are prefered where they exist.