Date: Mon, 21 Sep 1998 01:13:44 -0700 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), hasty@rah.star-gate.com, pfgiffun@bachue.usc.unal.edu.co, advocacy@FreeBSD.ORG Subject: Re: More on the Intel-UNIX standard Message-ID: <199809210813.BAA21549@word.smith.net.au> In-Reply-To: Your message of "Mon, 21 Sep 1998 07:52:32 -0000." <199809210752.AAA21173@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > With respect, I spent several hours today going over the public > UDI information. Here are some salient points: > > 1) It is a source portability standard, *not* a binary portability > standard. > > This means that you can not expect it to mean squat to the > source-available systems. I tend to disagree, and indeed you yourself below suggest why this isn't the case. > 2) The header files for pretty much everything are downloadable > from the SCO site, as are the man pages. > > This means it would be trivial to commit them. > > 3) There are no reference implementations of drivers that are > source-available to test a FreeBSD implementation. > > This means that you won't know that you've done anything. Not yet. These do exist, and as I understand will ultimately be available. > 4) There is support for dynamic attachment, but not for > dynamic loading of driver modules. > > This means that, whatever happens, it will be pretty stupid, > since you will need to expend kernel space on drivers that > aren't used in order to get drivers at all. This is Bad Bad Bad. You might like to point this out to Kurt at least. > > > Perhaps, someone from the commercial sector can step in : > > > Oracle, Yahoo, Whistle or Juniper. > > This is a good suggestion. Given #1/#3, it's a good bet that you > will need someone legally accountable to sign for source license > to a "select group" from a legal perspective. For which code components? I am aware that Kurt at least feels strongly about having an "open source" reference implementation, and that they're willing to bend over backwards to see this happen. > > > All of the above companies have architect class engineers and it is really > > > to their advantage to contribute something in this area. > > > > Oracle are no longer interested in FreeBSD (see John Dyson'ss > > swansong), > > BS. This is defeatist propoganda at its worst... Evidence to the contrary would be gratefully appreciated. And if you have some time (!), I'd love some help working out why Oracle 8 for Linux is dying under FreeBSD. > > Whistle are at the other end of the market (embedded systems) > > I'm at Whistle, and I think it's a good idea, but it will have some > overhead relative to FreeBSD that FreeBSD may not be prepared to > shoulder (FreeBSD is prepared to shoulder so little overhead...). We're prepared to shoulder lots. We don't have the resources to do so seriously. > > and UDI would be an unnecessary expense, > > I believe that both Archie Cobb and Julian Elisher would support > UDI at Whistle; I know that I would and that Bryan Mann would, which > means that you would have a hard time *not* supporting it there. > Whistle is an enlightened company; they know the difference between > "tactical" and "strategic", and, unlike most companies, have devoutly > embraced the "Open Source" thema for tactical developement. I'm happy to be wrong. > > Juniper aren't likely to care (UDI doesn't address any of their > > problems). > > The current UDI specification (.80) addresses both SCSI drivers and > network cards. Thus it addresses issues which Juniper find to be > both strategic and tactical (i.e., they will want the code, and they > will be willing to contribute code back; Juniper, like Whistle, is > aware of the issues involved in enlightened self interest). I wasn't of the impression that Juniper's relevant network hardware was being handled by BSD drivers, or that they had any trouble with the natively supported hardware they're currently using. > > I was unable to make any headway despite researching the matter > > intensely some time back; someone with no coding skills but some > > technical marketting acumen and more free time to spend on might-be's > > would have a better chance of coming up with the goods. > > You should probably point out that the BSD community, if included, > will be a ready source of commercially usable UDI code, since we > will not live without drivers for our own hardware. The Linux > community, to the contrary, will produce GPL'ed drivers that will > not be commercially usable. Vendors would argue that they would prefer to provide their own drivers. For a counter-argument to "vendor drivers are better", see the now extinct /sys/pci/tek390.c. > Consider the case (since UDI embraces CAM) of CAM-based controller > drivers with no development effort by commercial vendors, since the > FreeBSD counterparts will be generally available, and usable under > the UCB style licensing. Indeed. > Personally, I'd like to see some ELF binary UDI impelementation, such > that the code from card vendors would run under FreeBSD without the > need for a non-disclosure license and recompilation. Certainly, UDI is as close as we're likely to get to a cross-platform ABI for device drivers. We've been trying to bring UDI to USBDI (the cross-platform USB driver interface effort) as well, but are encountering more resistance. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809210813.BAA21549>