From owner-freebsd-hackers Fri Feb 16 8:57:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (ip181-180.nashville.com [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 77C3237B4EC for ; Fri, 16 Feb 2001 08:57:49 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id LAA27180; Fri, 16 Feb 2001 11:05:33 -0600 (CST) Date: Fri, 16 Feb 2001 11:05:33 -0600 From: Robert Lipe To: =?iso-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-hackers@freebsd.org Subject: Re: UDI environment now released. Message-ID: <20010216110533.T19689@rjlhome.sco.com> References: <20010214173141.J19689@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: ; from groudier@club-internet.fr on Fri, Feb 16, 2001 at 09:40:04AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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