On Thu, 12 Apr 2001, Stephen Welker wrote:

> Recently I have come across a concept that may be usefull for NetBSD. I 
> wish to make people aware of this concept so that it may be discussed in 
> the context of (1) NetBSD, (2) the ever increasing demand on new drivers, 
> (3) cross platform development, (4) a common/published standard for driver 
> writers, etc.
> 
> This new concept is the "Uniform Driver Interface".

I've been aware of it for a couple years now.  I've also heard of other
similear efforts that have failed, some going back many years.

> UDI, the Uniform Driver Interface, is a well-documented interface between a 
> driver module and the executing OS. It provides source portability across 
> OSes and binary portability within a processor ABI. It also provides modern 
> driver features like instance independence, high scalability, and physical 
> location transparency. The Reference Source provides an initial 
> implementation of UDI for Linux, SCO UnixWare, SCO OpenServer, and other 
> OSes.

There are some good things there that we would like.  For instances most
of their drivers are already SMP safe.  Those working with SMP will like
that.  However this illistrates a problem: overhead that isn't nessicarly
needed.   Now you can make the arguemeng that netBSD is moving to SMP so
this is good, but there are other things.

It boils down to: eventially someone writes a driver that is buggy when
doing foo, but since his prefered OS doesn't use foo he doesn't
care.  (indeed foo probably never was implimented, just some stubs so the
driver would compile)

One other point, generally they are slower then native drivers (claims to
the contary, a well written native drive tends to be just enough faster
that we use it instead.)  Of course when the native driver is poorly
written, or doesn't exist, this is a good alternative.  For drivers where
speed is not critical, a little overhead is fine.  However you will find
that vax and m68k users consider just about everything speed critical due
to the slow processor.

That said, it would be good to have a general interface.  If even one
manufacture decides not to release documentation, but can be convined to
drive a universion driver and compile it for all processors, then we
win.   So don't let me discourage you from going ahead.  It would be a
good exercise to make a system entirely without netbsd drivers, just these
universial drivers.   You will then be able to put in concrete examples of
why netBSDs model (while probably needing improvement) is better in some
way.