Well, as someone who's intimately familiar with UDI and SCO UnixWare
driver models, and slightly familiar with the driver models in Linux
and other more "normal" [sic] UNIX OSes (but willing to learn more :-),
I'd have to disagree with this (apparently somewhat common) perception.
I think you'll find that if you look closely, you'll find that UDI looks
less like most UNIX driver models than the Linux model looks like the
typical UNIX model. UDI does not have "mbufs", STREAMS, or any other
pieces of existing APIs. (There will, however, undoubtedly be concept
overlaps with various models, including Linux.)
UDI is not an amalgam of several companies' existing interfaces. It is
a new interface, defined from the start with portability in mind. The
Project UDI team early on realized that the only way to get true
portability between OSes was to stear clear of any existing proprietary
interface, for two reasons:
1) The "owner" of the proprietary interface would tend, good intentions
notwithstanding, to try to "pull" the spec back to their original
interfaces, since variations on existing APIs are harder to support
alongside current drivers.
2) The design goals and context for any proprietary interface, while
perhaps perfectly reasonable for the environment in which they were
created, are unlikely to have been focused on appropriateness for
other OSes.
So, we focused on building a clean abstraction, placing a clean dividing
line between what a device driver knows about its device and what an OS
knows about its architecture and policies. One of the key design goals
was that the resulting interfaces had to be implementable *efficiently*
on almost any OS. We recognized that it wouldn't do any good to have a
standard driver interface if noone was going to use it, and noone would
use it if it performed poorly.
Admittedly, designing an abstract interface that also performs well is
quite a challenge, but I truly believe that Project UDI has met that
challenge. I believe that UDI will not only be able to match performance
of existing interfaces, but with a properly tuned and architected OS
implementation, will in fact exceed existing performance and scalability
levels. However, I know that none of you will (or should) take me on
faith on this point. The proof will have to be in the practice. Once
implementations go beyond their current basic prototype level, we can
start to measure and see.
I know that several people have brought up the potential problems with
specifications designed by committee. I'm all too familiar with how this
often works (poorly, of course :-). I have to say that Project UDI has
been a pleasant exception. I'm proud to have been working with such a
well-oiled team of talented architects and driver writers, who have been
able to put aside their parochial corporate interests and work towards
a common vision, in many cases dedicating significant amounts of personal
time and with very little support from their management.
It is, by the way, due to the part-time nature of the effort until
recently that has caused it to move as slowly as it has. Fortunately,
we're now on an accelerated schedule, and a lot more progress is being
made.
BTW, let me introduce myself, since I stepped into this discussion
unannounced. I'm a senior architect at SCO, and I've worked on the
UNIX kernel for 10 years, following the original AT&T source base as
it moved from Bell Labs, through various AT&T subsidiaries including
USL (UNIX System Laboratories), Novell, and finally SCO. I have been
a part of the UDI team since before it was even called UDI, back in
1993 or so. Device driver interfaces are one of my focus areas, but
I also work in many kernel areas, including memory management and
filesystems.
-----------------------------------------------------------------------
Kurt Gollhardt email: kdg@sco.com voice: +1 908 790 2277
SCO Core OS Architect Murray Hill, NJ fax: +1 908 790 2426
-----------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/