Date: Fri, 16 Feb 2001 09:40:04 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Robert Lipe <robertl@sco.com> Cc: freebsd-hackers@freebsd.org Subject: Re: UDI environment now released. Message-ID: <Pine.LNX.4.10.10102160912170.742-100000@linux.local> In-Reply-To: <20010214173141.J19689@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10102160912170.742-100000>