Date: Fri, 16 Feb 2001 11:05:33 -0600 From: Robert Lipe <robertl@sco.com> To: =?iso-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: freebsd-hackers@freebsd.org Subject: Re: UDI environment now released. Message-ID: <20010216110533.T19689@rjlhome.sco.com> In-Reply-To: <Pine.LNX.4.10.10102160912170.742-100000@linux.local>; from groudier@club-internet.fr on Fri, Feb 16, 2001 at 09:40:04AM %2B0100 References: <20010214173141.J19689@rjlhome.sco.com> <Pine.LNX.4.10.10102160912170.742-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Gérard Roudier wrote:
> > A more recognizable reliabilty improvement is the more unified and
> > constitent programming interface. No more "you can't call malloc with
>
> This looks like matter of taste to me. Unless all O/S architects since day
> one until UDI have been incompetent idiots. :-)
Well, OK. If you don't mind, for example, having a different buffer
model for network devices than you do for storage devices, it is a
matter of taste.
> > > Why isn't UDI proposed as a native kernel interface, instead?
> >
> > In at least three OSes, it will be a native kernel interface in versions
> > shipping this year.
>
> How the 'open-ness' of UDI is guaranteed?
* The specification is open and freely available for download and use.
(www.projectudi.org)
* No royalties, membership fees, or initiation rites to contribute or use
the spec.
* Multiple implementations (including one with source under a BSD license)
are available for interop testing.
> - Are these three mysterious O/Ses using some vendor-specific extensions
> or undocumented differences in their UDI stuff?
I didn't mean to be mysterious:
* SCO UnixWare 7 has a vendor (that's me) supported UDI environment
available now as download. The next version will have it integrated
into the base OS.
* SCO OpenServer 5 will have a supported UDI environment in the first
half of this year as a download. The next version will have it
integrated.
* AIX/5L has a supported UDI environment in the current prereleases.
UDI will be available in the product at launch.
If there are driver-visible differences, they are
bugs and will be treated as such. And in some environments, we enforce
things like accessing no symbols other than what's in the spec. Name
your driver functions "lbolt", "kmem_alloc", "main" or anything else you
like; you're not getting to the non-UDI symbols in the kernel of the
same name. :-)
> - What the risk of UDI getting steered by some coalition of vendors?
If you want to help steer, come aboard. We'd welcome it.
Since we didn't start with some existing driver interface, it's not
self-serving to assert any undue influence on things. There's enough
architectural differences represented to keep things pretty neutral.
You can see minutes of the (open) meetings and calls on the web site.
> - Finally, as some large collection od UDI drivers may well exist, how can
> I download the source and how FreeBSD is intended to gain adavantage of
> this driver collection in the future ?
We're providing a few drivers on projectudi.sourceforge.net as samples.
It will be, as always, up to the driver owners to decide how and where
to distribute their drivers. If someone contributes a driver to the
project, I'll gladly drop it in the tree.
Now that the 1.01 specification is finalized and UDI is shipping as a final
supported product one OS (UnixWare 7) with two more soon (OpenServer, AIX I expect IHVs
> > many cases, you could even make UDI the primary interface and implement
> > another interface -perhaps the current interface for compatibility- in
> > terms of UDI. I'm looking at doing exactly this in some of my OSes.
>
> Was the main point of my question. Thanks for the reply.
Good.
> > Besides, if I walked into this crowd and said, "Here's a new driver
> > interface and a megabyte of patches to /usr/src/sys. Whaddya think?",
> > how quickly would you have thrown me out? That's what I thought. :-)
>
> A mega-byte large patch is not that unusual nowadays. :-)
Perhaps not, but if I had carved up gensetdefs to allow builds outside
the kernel source tree, changed the klm code to recognize .udiprops
sections in an executable, and made newbus a little more forthcoming
with information, don't you agree it would have been met with more
skepticism?
I just really didn't want to debug the host OS and the UDI environment
at the same time. I didn't do it when I did UDI for the OSes in my day
job, either. Maybe I'm a coward.
> > Now repeat that exercise for a dozen or so OSes...
>
> Only. :-)
Hey, I've gotta sleep once in a while. :-)
Speaking of not sleeping, I had a major cvs commit party last
night. I think I have all the FreeBSD code checked ito the udiref
tree now. I fixed a binary incompatibility problem and have now
successfully kldloaded UDI modules that were built on a UnixWare system.
(The Linux/OpenServer/UnixWare interoperability has already been
demonstrated.)
RJL
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010216110533.T19689>