From owner-freebsd-hackers Fri Feb 16 1:41:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id F065437B491 for ; Fri, 16 Feb 2001 01:41:13 -0800 (PST) Received: from nas1-147.mea.club-internet.fr (nas1-147.mea.club-internet.fr [195.36.139.147]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA10969; Fri, 16 Feb 2001 10:41:07 +0100 (MET) Date: Fri, 16 Feb 2001 09:40:04 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Robert Lipe Cc: freebsd-hackers@freebsd.org Subject: Re: UDI environment now released. In-Reply-To: <20010214173141.J19689@rjlhome.sco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Feb 2001, Robert Lipe wrote: > G=E9rard Roudier wrote: >=20 > > Being smart with kernel interface is important for drivers to be fast a= nd > > reliable. Puting some stinky layer between native kernel interfaces and > > drivers looks horrible to me. >=20 > Fast and reliable are both covered. >=20 > For example, the specification (though not the current reference > implementation) allows things like having different drivers and even > different instances of the same driver in separate address spaces. Want > to debug your driver in user space? It could happen. Reliability > can be realized by making it impossible for a driver to panic the > system. (And I do realize that flies directly in the face of fast. :-) Certainly not full impossible. DMA at some wrong place or not handling properly level-triggerred interrupt, for example ... > A more recognizable reliabilty improvement is the more unified and > constitent programming interface. No more "you can't call malloc with > WAIT_OK while holding a spin lock on another processor at an elevated > PL" bugs. This looks like matter of taste to me. Unless all O/S architects since day one until UDI have been incompetent idiots. :-) > > Why isn't UDI proposed as a native kernel interface, instead? >=20 > 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? As a corollary: =20 - Are these three mysterious O/Ses using some vendor-specific extensions=20 or undocumented differences in their UDI stuff? - What the risk of UDI getting steered by some coalition of vendors? - 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 ? > The current "UDI Demarcation Point" isn't fixed. It can be moved to > suit the needs of the host OS. As a practical matter, the thickness of > that "layer" is very slim at runtime, so the potential gains aren't as > large as some imagine they are. I want to beleive you here. > In its early life, a very natural way to bring up the UDI interface > (remember, we were developing spec, drivers, and environment > simultaneously) was to do it in terms of existing kernel interfaces. > UDI and the existing interfaces could be implemented side-by-side. In > 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. > 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. :-) > Now repeat that exercise for a dozen or so OSes... Only. :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message