News Group Posts

udi universal driver interface

The Linux UDI page seems not to have changed much in the past decade and the arguments in favor of UDI haven't changed either.

Neither have the arguments against.

Message-ID: <394B2EA6.316BA9D3@etr-usa.com> 
Date: Sat, 17 Jun 2000 01:54:14 -0600
From: Warren Young <warren@etr-usa.com>
Newsgroups: comp.unix.sco.misc
Subject: Re: SCO Linux???
X-Original-NNTP-Posting-Host: 56k111-118.cyberport.com

fred smith wrote:
> 
> Robert Lipe <robertlipe@usa.net> wrote:
> : Warren Young <warren@etr-usa.com> writes:
> 
> :>I guess it's a given that [SCO will] integrate the UDI patches that the
> :>core Linux kernel development team refuses to use.
> 
> Pardon my ignorance, what is UDI, and what would its presence do for/to
> Linux?

It's a standardize device driver interface.  The idea is for all Unixes
to support it, allowing a device driver to be ported to new versions of
Unix with just a recompile.

(See http://www.projectudi.org/ for more details.)  

The current sentiment among the Linux kernel people is that they don't
want UDI in the kernel.  I've heard several reasons for this:

1. UDI -- being an extra layer of indirection -- slows the device driver
down with respect to a "native" device driver.

2. The Linux kernel people would rather see native drivers than UDI
drivers for particular hardware.  If UDI remains an add-on that Linux
distributors have to add themselves, there will be more pressure on
hardware vendors to avoid UDI, at least for Linux.

3. Since UDI is a standardized interface, it should also be an ABI, at
least for a particular platform.  (UDI doesn't promise a cross-platform
ABI.)  An ABI means that a device driver could work with multiple
versions of the Linux kernel without needing to be recompiled.  

If Linux had a driver ABI, hardware vendors would start shipping
binary-only drivers: there are few binary-only Linux drivers right now
because of the threat of interface changes.  Obviously, binary-only
drivers go totally against the grain of Open Source.

4. There's concern that UDI would create a drag on kernel innovation:
that UDI would either make some kernel changes impossible because of the
way it thinks device drivers should work, or that the UDI component
might not be able to benefit from improvements made to the native driver
interface.  The latter would make Linux look bad if UDI became the de
facto Linux driver interface, because the improvements would not show up
on systems using UDI drivers.  The Linux kernel folk would then have to
petition the UDI standards body to make a change: Open Source and
bureaucracies do not mix.

5. Accepting UDI into the kernel would require the kernel folk to find
someone to keep the Linux UDI component in synch with the rest of the
kernel.  Since UDI is already unpopular for the above reasons, there's
skepticism as to whether someone can be found that's willing to synch
UDI up every time the native driver interface changes.

6. ABIs are good in one sense, but they also stifle innovation.  Just
look at UnixWare: their DDI is at version 8 right now, implying that
they've changed the interface 7 times since they created DDI.  Linux
changes its device interface as often as every point release.  Is Linux
out of control and chaotic, or is it continually being refined?  It
depends on your point of view, but the fact is, the Linux kernel folk
refuse to give up this ability to change the device driver interface at
will.

-- 
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

From - Mon Jun 19 06:22:18 2000
From: Robert Lipe <robertlipe@usa.net>
Newsgroups: comp.unix.sco.misc
Subject: Re: Merits of UDI. was: SCO Linux???
Date: Sun, 18 Jun 2000 18:12:13 GMT
Message-ID: <skq47ttoe7f12@corp.supernews.com> 

Geoff Johnson <gpj@saki.com.au> writes:

>A real fear of the Linux community is a takeover of Linux by stealth.
>One way to achieve this is to enable binary only facilities. Then anyone
>with the money could dominate the business by suppling superior binary
>only code and lock out other developers. Eventually making industry
>dependant on the private facilities. 

I really don't get this argument.  It seems to go to "Let's change the
interfaces rapidly and show blatant disregard for compatibility so we'll
have more drivers."

>SCO should make a sweeping statement to the extent that any drivers they
>supply will include full source. This would disarm most of the anti UDI
>camp. How much competition is there now that SCO has to keep the Scroog
>mentality on the source code. (How much of the drivers come from SCO
>anyway? How much comes directly from the hardware manufacturers?)

SCO is but one partner in UDI.  SCO has currently contributed
the majority of the sample drivers that will be in the reference
implementation and are available now in the UW UDI Developer's Kit from
our web page.  They are available as source.  But statistically, the
majority of the interesting drivers on the planet will not be ours so I
don't know what good such a sweeping statement would really make.

>How many hardware manufactures hate developing UNIX drivers. My guess is
>most of them. Why not use the army of willing linux slaves to maintain
>the drivers. 

I don't think any serious hardware vendor depends on "willing slaves" to
support their product.

>Linux desperately needs this interface and the related facilities to run
>it. I have hacked kernels for 20 years. Looking at linux is like being
>transported back to the begining of time.

In more ways than one.  Yeah, there's the obvious absence of things
liek strongly versioned interface, but more interesting (to me) is the
mentality time-warp.  The "we like our proprietary interface that we
will change at will just to force you to buy into our system" seems so
very 1980's to me.  There are certainly folks that won't put up with
that.   

>Veritas will never release the code to their file system. Many other
>companies have great things to offer that they cannot, because of the
>gross version dependancies that not having facilities like UDI cause.

Precisely.   That's a good example of the above.

>With UDI you can have your cake and eat it too. If you want the source
>badly enough reengineer it. Having the UDI gives you the possibility of
>binary only drivers that can last many years without modification.

Yes.

>The performacne issues are a complete furphy. UW drivers can be slower
>but not so much much that last months processor upgrade does not blow
>away the difference. Use the X philosophy: design it properly because
>the performance will ALWAYS be here very much sooner than you think.

They can also be faster.  For example, on a two-processor system let's
say you have two SCSI adapters controlled by the same UDI driver.
Becuase of the instance independence, the OS is free to schedule each
driver region at the same time on each processor.  The driver doesn't
know it's happening and doesn't have _any_ locks in it.  All the
necessary locking is done in the UDI environment where they're easy to
inspect for lock contention and correctness.

They can be more reliable.  UDI drivers can run in independent domains.
So if you wanted to plumb a driver on this system to that system via a
TCP connection, that can happen.  If you wanted to a UDI driver in user
space (with no changes to the driver) during driver developmet, that can
actually be done within a UDI environment that supports such things.  If
your driver instance does something fatally naughty, the UDI environment
has all the information it needs to deallocate all the resources you had
allocated and notify everyone that's connected to you that you've been
shown the door.  (Thus potentially making it impossible for a driver to
panic the system!)


RJL
 

From - Tue Jun 20 17:59:49 2000
Message-ID: <394FD3C4.46395DF7@etr-usa.com> 
Date: Tue, 20 Jun 2000 14:27:48 -0600
From: Warren Young <warren@etr-usa.com>
Newsgroups: comp.unix.sco.misc
Subject: Re: Merits of UDI.  was: SCO Linux???
X-Original-NNTP-Posting-Host: 56k139-118.cyberport.com

Geoff Johnson wrote:
> 
> > It'd be better if they developed the initial driver for the native Linux
> > driver interface instead: even more of the free Linux labor pool will
> > chip in to to help maintain that than a UDI one.
> 
> I never said that the linux community should do the original
> development. I said they should do SOME of the support.

You misunderstood my comment: "they" refers to the hardware company. 
The hardware company develops the original driver as a native Linux
driver, which the Linux community can maintain.

Obviously that vision only works if you also buy my argument that Linux
will eventually make all the commercial Unixes obsolete.

> > "Interoperability" is a Costco bulk-size joke.  It's time to pick one
> > strong vision and go with it.  Isn't that how Unix got started?
> 
> Its also how UNIX fragmented about five minutes after it was invented.

Unix fragmented because every vendor started with one of the two
original Unix flavors, and then wanted to add feature FOO, but they
never shared code or even designs for that feature, so every
implementation of FOO was different.  Add in features BAR, QUX, BIFF and
GARPLY and you arrive at the current mess in commercial Unixes.

If FOO et al. had been in the original version of Unix, Unix wouldn't
have fragmented.  No one has renamed grep or cat or creat(), no matter
how much people have complained that they're stupid names.  These
commands and functions are Standard.  They're Standard because they
existed in the common code base, not because Ken Thompson or AT&T or the
IEEE said they should be The Standard.

POSIX was a vaguely successful attempt to get vendors to share designs. 
POSIX didn't actually create much of anything, though: they just
standardized the existing designs everyone already had in common.

The places where POSIX tried to do something original or standardize on
one vendor's implementation have almost all been withdrawn from
consideration by the IEEE.  The POSIX print administration committee  --
just as one example -- died of squabbling, so there is now no standard
way to admin print jobs.  Other failures include POSIX security
extensions, removable media handling, multiprocessing extensions, and
user interfaces.

The GPL is the path out of the trap.  It enforces code sharing between
vendors.

In a way, the Single Unix Specification is the a standard of the same
kind I'm proposing Linux should become: a bunch of people that use a
common code base stand up and say, "We're a Standard now!  If you want
to be Standard, too, license a copy of the common code base."  No
fragmentation, no multivendor compromises, no slightly-nonstandard
variations for a certification committee to accidentally overlook.

So why Linux and not Single Unix?  Bear with me and I'll explain my
logic.

I think SCO's Linux division will make money: it won't need to be
subsidized by their commercial offerings.  If that happens, it follows
that they could give away UnixWare's code and continue making money.

I seem to recall that Sun paid a lump "forever and ever license fee" to
SCO right after SCO bought Unix from Novell.  IBM probably won't pay
royalties to SCO after the Monterey merge finishes.  HP....I guess
they're still paying Unix royalties, but it probably doesn't amount to
much, and it's got to be declining.  Compaq/DEC and SGI are busy trying
to beat each other to the "Our Unix doesn't matter any more" finish
line.

Even if Unix vendor licenses still matter to SCO, how much longer can
they be a useful revenue stream?

Let's say SCO no longer derives a useful amount of money from vendor
licenses.  Why not give the code away to kill Linux?  It would work,
without question, immediately.  OK, not so much "kill" as "permanently
maim".  But SCO didn't do that: instead they came out with their own
Linux.  Why?

The remaining UnixWare revenue streams are end-user license fees and
support contracts.  

Support is a given.  SCO could fire its development staff tomorrow and
live for years on support contracts.  (ESIX still exists for that very
reason.)

Conclusion: SCO won't GPL the core UnixWare code because it needs the
license fees.

Final conclusion: if you think a free OS is a good idea, UnixWare won't
be it.  That's why I give Linux the nod.

> Linux kernel design is a "weak" element. It is fast reaching the stage
> that gcc reached where a "private (but still open)" group will have go
> away into a corner and clean it up. UDI or its equivalent in terms of
> driver design strength ia absolutley necessary if Linux wants to get
> into the multi CPU systems as a real contender. Dead lock avoidance is
> not a job for amatures with third rate design tools.

Tools are never the most important element of a development effort. 
There are no silver bullets.  Human ingenuity is far more important than
magic tools, and all the evidence points to the Linux community as
having plenty of that.

I don't dispute your GCC comment: all open source projects of any
complexity have to have a focused design team.  GCC lost its team when
RMS decided to stop hacking and start politicking full time.  Linux
still has its original designer.  Even if Linus should go away some day,
there are several benevolent-dictators-in-training.

Cygnus picked up the GCC mantle.  Cygnus is now part of Red Hat.  Red
Hat is a company that employs several of the "amatures" that work on the
Linux kernel.

No amateurs, no missing design team, and no one gives a damn about the
tools.  What other fatal flaws do you see with Linux?
-- 
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

Comments?

More Articles by Tony Lawrence

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.