I and any of the other UDI folks would welcome discussions with LI's
Executive Director. Please have this person get in contact with me by
email or telephone (see my .sig).
> >
> > >
> > > Note that UDI has been around for years --- companies have been working
> > > on this since 1993. Hence, in a long-running project like this, almost
> > > everybody will have slightly different visions about what its goals are
> > > and what they hope to achieve.
> >
> > This is true. Given the number of years I am sure that their hopes
> > and expectations have also become confused.
Project UDI is specified in a series of 5 books. Each book discusses
a different aspect of UDI and they tend to increase in complexity as
you progress through the books (excepting the books that aren't
written yet and are therefore very easy to read :).
Book 4 is the actual detailed specification for UDI. As with most
specifications, some more descriptive context is very helpful in
understanding the specification.
Book 3 provides some of the description although it's presently out of
date relative to Book 4 (note that all of this is a work in
progress...)
Book 1 is also known as the "UDI White Paper" and has several sections
including a UDI History. I'd recommend reading that section to
understand some of the motivations and history that got us here where
we are today.
The books are available at our web site: http://www.sco.com/UDI
> >
> > >
> > > Quite frankly, I don't understand the comments in the press release
> > > about their hoping that the Linux community will provide UDI drivers for
> > > all of these devices. That simply doesn't make any sense; a native
> > > driver will be faster, more efficient, and in all likelihood, easier to
> > > implement. And whether you write a UDI driver or a native driver, you
> > > still need the cooperation of the manufacturer to give you programming
> > > specs.
> >
> > If we take Mr. Kevin Quick's statements as they are stated in the
> > article it would seem clear what they want. The reference platform
> > will be released as "freeware" ( I am assume GNU GPL since it would have
> > ti link with the kernel. ) to the Linux Community, and the Linux
> > Community is to undertake the "daunting" task of writing all those UDI
> > device drivers. Once we have written them the commercial OS vendors and
> > peripheral vendors will use our work as a "basis" for their work.
I spoke with a couple of press editors on the day Intel made their
press release. These were somewhat free form "essay answers" to a few
general questions posed by those folks. Please understand that I'm
not disparaging the press here, but when they take written notes by
hand during a 30-minute interview and subsequently write an article
for publication, the context of some statements is misleading or mixed
with other statements.
[There are also bad points to the press, such as the completely
abstruse, generally incorrect, and poorly researched articles
regarding this subject that appeared in the Wall Street Journal recently].
What my intent was in the above statement was that developing drivers
for the wide range of adapters and other devices available today is a
"daunting" task. Re-developing those drivers N number of times to
support N number of operating systems is even more daunting. Project
UDI is attempting to reduce N to a very small number (potentially
"1"). Because of this tradeoff, the Linux community can directly
benefit from drivers developed by hardware manufacturers and other OS
vendors. Likewise, the substantial capabilities of the Linux kernel
developer community can also benefit the driver support issue.
This will be threatening to some people. When adapter vendor X
introduces adapter Y along with a UDI driver, there will not be a need
for a new driver to be developed for OS's which support UDI. Some
driver folks may find that they don't need to do as many drivers
(although this is not to say that there can't be multiple UDI driver
implementations for the same adapter Y).
This will be benificial to a lot of people. When I run OS Z on my
system, I don't have to wait for vendor X, Linux developer D, or
internal engineer E to develop the driver for OS Z to be able to use
the device. If OS Z supports UDI I can use the driver supplied by
vendor X regardless of what the value of variable Z is.
And of course, this is a change to the current way of doing
things... there's always both good and bad in any change. The
challenge before Project UDI (and all of us) is to maximize the good.
'Nuff said, I'm getting too pedantic.
> >
> > Look at the time line:
> >
> > UDI started in 1993 still no complete specification. February 1999 it
> > is due out. Linux since 1993 with no "official" specification has native
> > drivers are many of the peripheral on the market. There may be a time
> > lag between the peripheral first hits the market and when there is
> > support
> > in Linux for it but eventually most are supported. What "group" has
> > more expertise at writing device drivers than the Linux Community?
> > None come to my mind readily.
> >
> > >
> > > What's much more likely to happen is that hardware manufacturers will
> > > start shipping UDI drivers with their hardware, and that will allow them
> > > to ship, say, Winmodem cards that will actually work on operating
> > > systems other than Windows 95. (Winmodems currently don't even work
> > > under NT).
> >
> > I do not have that feeling. They do not want Winmodem drivers they want
> > the "serious" stuff, SCSI and Network. Remember the context of the
> > article
> > is about Intel-arch UNIX servers. Servers basically require two things
> > disks and bandwidth.
The goals of Project UDI are congruent with but not precisely the same
as the goals of Intel's involvement in Project UDI. Intel is focusing
on the Unix community. Project UDI has developed the UDI
specification to be valid in any number of environments from small
embedded environments up through workstation and server and
(distributed) supercomputer environments. Most of the developers are
Unix-centric, but there's a great deal of driver experience in the
Project UDI participant's history, including non-Unix environments.
The present focus of UDI is to encompass a broad range of devices with
different operating characteristics that allow us to have an
appropriate breadth in the specification. However we also have
limited bandwidth. Therefore we have chosen storage and LAN
networking as the initial focus. We do feel that UDI is appropriate
for almost all devices, we just haven't gotten there yet.
> >
> > >
> > > Given that scenario, my personal take is that UDI is relatively
> > > harmless. But before we start send a formal response, we should make
> > > some informal contacts first. And one of the first questions I would
> > > ask is a fuller explanation of their vision about the Linux community
> > > providing UDI drivers. What they've written in their press release
> > > simply doesn't make any sense. (But that's most likely a failure by
> > > some marketing dweeb who was writing the press release than evidence of
> > > something dirty and underhanded. "Never ascribe to malice what can be
> > > adequately ascribed to stupidity.")
> >
> > I do not see it as harmless. If the Linux Community "buys" into Project
> > UDI
> > without getting I2O opened up, we are dealing with the same
> > participants.
> > Using the analogy that Alan Cox used, it is hard to shake the right hand
> > of Project UDI when the left hand is on the binary-only sword of
> > I2O.
Project UDI is separate and distinct from I2O. We have a statement
regarding this on our Web page, and I'll be posting another separate
email on this subject later but they are not mutually exclusive nor
are they a joint effort. The real glue between UDI and I2O is Intel's
involvement and this will help clarify the distinction and increase
the synergy.
> >
> > Which I why I advocate the price for our help that I do.
> > Basically the price translate to:
> >
> > We will help provided you remove your other hand from the
> > binary-only sword of I2O. Please kindly show us two open hands.
> >
> > That I hope LI's Executive Director conveys to them either informally
> > or formally, just as long as it is conveyed.
As stated above, these are separate entities although the press
information wasn't very clear about this which is where the above
statements arise.
The operating model for the two organizations is different:
Project UDI is open to everyone and the specifications are available
on the web site. We have developed a prototype implementation for
several devices and operating systems. This prototype is not
presently available to the public but most of it will be moved into
the public domain over the next few months. Intel will be developing
the Linux UDI support (via Sunil Saxena's group) which they will
provide as freeware as well.
I2O maintains a SIG with a steering committee and cost-based
membership to offset the development and marketing efforts (in
contrast, UDI development and marketing are volunteer funded which
partly explains the low levels of marketing to date and the length of
the development of the specification).
> >
> > >
> > > - Ted
> >
> > --
> > Terry L. Ridder
> > Blue Danube Software (Blaue Donau Software)
> > "We do not write software, we compose it."
> >
> > entertaining angels
> > by the light of my computer screen
> > 24-7 you wait for me
> > entertaining angels
> > while the night becomes history
> > host of heaven, sing over me
> > ==Entertaining Angels==Newsboys
> >
> > -
> > 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/
> >
>
>
> --
> David Hollister Interphase Corporation dhollist@iphase.com
> Software Engineer Dallas, TX
> http://www.public.asu.edu/~dhollist
>
-- ________________________________________________________________________ Kevin Quick Interphase Corporation Engineering Dallas, Texas kquick@iphase.com http://www.iphase.com 214.654.5173
- 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/