Date: Wed, 14 Feb 2001 22:42:12 +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.10102142233140.1547-100000@linux.local> In-Reply-To: <20010214000454.Y14300@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Why isn't UDI proposed as a native kernel interface, instead? Note that last time I read the specs, I haven't been this impressed.:) G=E9rard. On Wed, 14 Feb 2001, Robert Lipe wrote: > I'd mentioned a few times on this list that I had tinkered with a port > of UDI, the Uniform Driver Interface, to a FreeBSD environment while > waiting for our lawyers to get their acts together[1]. Well, I got the > final clearance and the code was released today at: >=20 > =09http://projectudi.sourceforge.net >=20 > The FreeBSD environment isn't included in the release yet, but from here > it's merely an editor exercise to release that pile of bits. The common > code is all there and I think there are only two or three mods to common > code required for the FreeBSD port. I hope to get it checked into the > udiref tree this week. >=20 > I'm not a FreeBSD jock, so I focused on getting the "UDI parts" > under control more than taking advantage of FreeBSD services. It > works well enough now that the remaining pieces could probably be > developed independently. For example, a SCSI mapper could probably be > stamped out by someone that knows the FreeBSD storage system and is > comfortable reading the Linux, UnixWare, or OpenServer SCSI mappers and > understanding only a very small amount of UDI. Similarly, someone that > understands the FreeBSD DMA system could grow the DMA implementation in > relative isolation. >=20 > I have it hobbling along well enough that a network driver running in > isolation (not talking to the network stack) will bind, deliver/service > interrupts, and do DMA long enough to deplete VM becuase of the leak > in contigmalloc. (Yes, yes, I know this is still evil...) There are > a couple of Really Horrible things I did to get the FreeBSD stuff up > rapidly, but I'd like to work with interested parties to get it going > well. >=20 > I'm a little torn between just checking in what I have now (including > horrible 4.1.1 newbus bus enumeration hack and special cases for a > specific PCI ID that I was testing) en-masse or dribbling it in as I > clean it up. I'm leaning toward the former, but a strong partner could > change my position to the latter. >=20 > RJL >=20 > [1] Try getting a dozen lawyers from some of the largest computer > companies you can name to agree on anything... >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 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.10102142233140.1547-100000>