[lkml]   [1998]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux, UDI and SCO.
Gerard Roudier writes:
> On Tue, 22 Sep 1998, David Hollister wrote:
> > Gerard Roudier says:
> > >
> > > I have had a look into UDI books. This looks to me as the result on N
> > > years of brain masturbation from 'has been' people that enjoy turning
> > > simple things into complex ones since this makes feel them intelligent.
> > > Let me doubt that a driver blindly written using these specs will work
> > > without change on any architecture and be optimal enough not to be
> > > ridiculous. All the UDI kernel interface reinvention will make debugging
> > > a pain. What about the overhead in code lines and CPU cycles due UDI
> > > stuff ?
> >
> > The reason it's so complex is because all the *nix implementations are so
> > different. It's quite an undertaking to attempt to create a standard interface
> > among such varying implmentations.
> A standard must allow differentiations and UDI is just trying to do the
> opposite at driver level, as does I2O. So UDI is a _bad_ driver standard.

Not so. UDI is standardizing the way that the driver and the OS
communicate. It does not tell you how to write your driver. It
doesn't tell you that copying your data internally is bad or anything
like that. It does not tell you how to design your interface to your
hardware (which I2O does do). It does not tell you what features and
functions you can provide beyond requiring the basic functionality
required to participate with the OS.

> We know that:
> - The unified form of life is the dynosaur.
> - The unified car model is the trabant.
> Do you want us to become dynosaurs driving trabants?

Not sure what a trabant is. However, I do like to know that the
steering wheel turns the car and that the pedal on the right is the
accelerator. Admittedly the layout of the controls in a car are a
de-facto standard whereas UDI is more of a voluntary consensus
standard, but the effects are the same. Nothing in either standard
defines the effectiveness of either type of driver, but it does
provide them a consistent operating environment.

> > UDI prototype environments (without kernel modifications, of course) already
> > exist for Solaris and HP-UX. I don't know about performance numbers but as
> > I've said before, our own UDI-ish driver interface which is designed along
> > somewhat the same lines as UDI has shown no real noticable performance
> > difference for our HP-UX implementation (I'm not sure of Solaris performance
> > numbers). I also have a Linux implementation which has also shown very
> > similar performance to a native Linux driver I also wrote for one of our FDDI
> > devices.
> Sun has developped a navigator under Java to promote their thing. This
> does not mean that any Java applications will have the same
> characteristics. I donnot doubt that high skilled and paied programmers
> are able to write good UDI drivers. Pay me a lot and I will try to write
> some UDI drivers. ;-)
> On the other hand, UDI model may fit very well some O/S design but may
> need bunches of bad glue code for some other O/S. A standard must be
> _fair_ or really try to be so. My reading of UDI models let me think it is
> not. BTW, the fact that SCO, Solaris and HP-UX already have UDI
> environments tells me suspicious things about the fairness of UDI
> specs.

You've not provided a definition or context for fairness so I can't
really speak to that point. However, SCO and HP-UX and Digital/Compaq
(among others) already have UDI environments and this tells me good
things about their investment in communal research. Solaris doesn't
count... I wrote the UDI environment for Solaris not Sun... this
should tell you favorable things about the fairness of UDI specs.

> > > I am not against UDI. In fact I don't care of such proposal. I want an
> > > O/S that fits my needs, and for now I have one that did'nt need UDI in
> > > order to be so.
> >
> > UDI isn't geared toward users. It's geared toward driver developers. Once
> > an OS environment is in place, you don't need to worry about it. You write
> > a new driver to drive some piece of hardware with the knowledge that all of
> > the OS dependencies have already been taken care of. It's a tool for more
> > rapid, standardized driver development. Whether the drivers your OS uses
> Look at applications developped under some rapid development tools. They
> are generally not maintainable and so have to be rewritten each time you
> want to add some feature.
> If it was possible to develop rapidly software, M$ would'nt have hired
> 10,000 people for their R&D department.

The "rapid" aspect of UDI is that once you've done the driver for UDI
under Linux, you don't spend more time on the Solaris version, then
more time on the HP-UX version, then more time on the SCO version,
then more time ...

M$ wouldn't be spending time and resources developing a common driver
model for their OS's if they didn't think this was a good/competitive
thing either.

> > are written to UDI or not has no bearing on your use of that OS.
> OS differences is a good thing. That's the resulted differentiation that
> makes Linux better due to BSD projects and vice-versa.
> Everybody doing exactly the _same_ things leads to everybody doing the
> _wrong_ thing.

Everybody uses sockets. Everybody uses read/write/ioctl. Everybody
uses C libraries. [OK, not *everybody*, but you get the idea.]

I don't think everybody doing things with the above is doing the
_wrong_ thing and I don't think this will apply to UDI either.

> Regards,
> Gerard.
> PS: Let me know how many UDI drivers are currently shipped with commercial
> O/Ses and at which URL(s) I can grab the source code.

None yet. Stay tuned.

Kevin Quick Interphase Corporation Engineering Dallas, Texas 214.654.5173

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.058 / U:0.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site