Date: Wed, 14 Feb 2001 17:31:41 -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: <20010214173141.J19689@rjlhome.sco.com> In-Reply-To: <Pine.LNX.4.10.10102142233140.1547-100000@linux.local>; from groudier@club-internet.fr on Wed, Feb 14, 2001 at 10:42:12PM %2B0100 References: <20010214000454.Y14300@rjlhome.sco.com> <Pine.LNX.4.10.10102142233140.1547-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Gérard Roudier wrote: > Being smart with kernel interface is important for drivers to be fast and > reliable. Puting some stinky layer between native kernel interfaces and > drivers looks horrible to me. Fast and reliable are both covered. 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. :-) 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. > 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. 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. 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. 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. :-) Now repeat that exercise for a dozen or so OSes... 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?20010214173141.J19689>