Date: Mon, 21 Sep 1998 07:52:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: hasty@rah.star-gate.com, mike@smith.net.au, pfgiffun@bachue.usc.unal.edu.co, advocacy@FreeBSD.ORG Subject: Re: More on the Intel-UNIX standard Message-ID: <199809210752.AAA21173@usr09.primenet.com> In-Reply-To: <199809210326.UAA02832@word.smith.net.au> from "Mike Smith" at Sep 20, 98 08:26:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Redirected to -advocacy, where this sort of invective is probably more > appropriate. > > > I am the wrong person for this task because I don't have time. > > Well a fat lot of use you are then. 8) > > Seriously, what value is there in saying "someone should do something > about this"? Of bloody course someone should, and the only someone to > do anything has done everything I can, and the last thing I need is > someone that's unwilling to do *anything* telling me that something > more needs to be done. > > You still need to learn that being an advocate means *doing* something, > not whining about what you think "someone else" should be doing. 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. 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. 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. > > 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. > > 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... > 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...). > 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. > 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). > Yahoo would only be interested if there was something UDI had to > offer them (and right now that's nothing). Vendor supported SCSI drivers. > UDI will come to FreeBSD when either a) it ceases to be vapourware and/ > or b) it has something to offer someone such that it becomes worthwhile > to invest in it. Certainly, it's vaporware at the present (for the most part), and certainly, Open Source is more likely to provide code to UDI than UDI is to result in vendors supplying code to Open Source. But in the long run, an enlightened self interest is a powerful thing. Look at the recent relicensing of X11R6 by the Open Group under the original X Consortium terms, for a counter-example to your claims. > My goal was to convince Intel that a deliverable for the BSD > environment would be more widely useful as a reference implementation > than one for the Linux environment. That is certainly true. > 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. 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. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199809210752.AAA21173>