Date: Mon, 10 Jan 2000 09:41:44 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Peter da Silva <peter@taronga.com> Cc: hackers@FreeBSD.ORG Subject: Re: Project UDI? Message-ID: <Pine.BSF.4.05.10001100924170.89509-100000@semuta.feral.com> In-Reply-To: <20000110143235.CD93E32306@citadel.in.taronga.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, I've looked at it. It's a very bad idea. I know some of the people involved, and I spent a substantial portion of the early 90's running aroudn doing the DDI at Sun with the notion it would bring a grand interface for all Unices.... etc... I've seen many, many, efforts in this area. I believe that this is just the wrong thing, now. As someone who develops drivers for multiple platforms I should be interested in this, but I'm not. It's solving yesterday's problems today at tomorrow's prices. The differences between *BSD, Solaris, Linux, AIX and NT for doing drivers is really not a substantial leaf node driver problem as most of these efforts try to address- all of these platforms offer more or less the same services to drivers (mapping registers, thread synchronization of varying kinds, memory allocation. Careful design and modern compilers have made code sharing between all of these platforms with macros && inlines both relatively straightforward and not that inefficient. The real issue then becomes both nexus driver issues and data structure and data movement issues- in this case, IIRC, UDI takes more the approach NT takes in that there are implicit marshalling/demarshalling domains between layers. When you have a huge single product line where you have multiple disjoint variant bus interconnect pieces that can plug together that require substantially different device methods, this approach is cool- this is why the DKI/DDI for sparc was such a great idea- you could have massive main and secondary I/O bus variation and both leaf and a large number of nexus drivers don't have to change- very cool for binary distributions. However, the world is a lot different now. There are a greatly reduced number of different types of hardware that have to programmed differently, and those that would otherwise need to tend to have this solved by h/w engineers who don't want to wait 2 years for the software to be written. The world is also moving to an open-source model so VARs needing binary plugin types of systems is somewhat less critical than it used to be (don't even *begin* to mention win32/NT being a binary plugin model as everyone and his mother has to have separate distributions for each Service Pack release). So the need for such complexity to solve hardware interconnect issues is a helluva lot less than it used to be. The other problem- data structuring- is not really a solvable problem. If your network stack and drivers works in units of mbufs, it's going to have to go through all sorts of contortions for the same driver to do streams as well. Note that both mbufs && streams stacks can exist in the same kernel, so maybe this isn't as good an example as it could be, but I think we'd all agree that the efforts of data structure/movement encapsulation for a single driver to cover multiple systems could be tough. There was a paper at the last Usenix about this (someone help me out here and dig out the reference)... That's my .02 cents..... On Mon, 10 Jan 2000, Peter da Silva wrote: > > Anyone had a look at this? > > http://www.project-udi.org/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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.BSF.4.05.10001100924170.89509-100000>