Date: Sat, 26 Jul 1997 12:44:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: stesin@gu.net Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4.2MP source code has become available recently? Message-ID: <199707261944.MAA02911@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970726001142.1361D-100000@trifork.gu.net> from "Andrew Stesin" at Jul 26, 97 00:20:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> On UW. Solaris is SVR4.0 heavily modified by Sun, > with SMP added by them independently; UW is SVR4.2 with > SMP added by USL, am I right? So they might have > some (in theory, at least) interesting differences with regard to > SMP implementation? Not as much as you'd imagine. It's basically differences in wrapping, more than anything else (ie: cosmetic). > Then VXFS; binary compatibility stuff; drivers. The VXFS belongs to Veritas, and is not relicensed. For what that's worth, all of the VXFS directory code is USL UFS derived (and it has USL copyright notices all over it). The binary compatability stuff is... "different". With the exception of enabling alrentate processor instruction sets in Solaris implementation (it uses an external program to do the deed for SunOS compatability), they are nearly identical. The x86 stuff is about the same (both have SCO and Microsoft copyrights all over the place). All in all, I would say it is inferior to either BSD approach that is out there; the instruction set stuff can be handled rather easily on BSD by trapping at the system call level (at least for BSD's that didn't follow Linux's lead on register paramter passing to system calls, making the ABI dependent on wordsize). Basically, it's no different than deciding to load an "interpreter". The program mmap's the executable into it's address space as data, and then "executes" the code via simulation. For system calls, the conversion from the emulated to the local is rather trivial (there are a number of issues regarding non-native x86 binaries being run on non-x86 architectures; they require either duping the system call conversion glue for the execution class in the user space simulator, or seperate simulators to invoke seperate system call lists still in the kernel). > SCO is dropping old SCO OpenServer aka SVR3, > in favor of SVR4.2MP-based system, I think; for now it's UW. > And they have some kind of "unified driver interface" spec for UW. > How nice would it be -- to have an ability to use hardware > vendor's own drivers for UW, compatible with that spec, > just out of the box. Aaghh, dreams, dreams... :( The net drivers are ODI. The ODI spec is available from Novell (if they think you are a card vendor) or from USU via anonymous FTP off their NetWare archive. Personally, I would not recommend using ODI; the ODI drivers lost 8-15% (depending on the card) over the native UNIX drivers they replaced. In addition, they added a streams stack transition (not an issue for BSD, I know) for inbound packet puts, which added an additional 7% latency. This was determined using formal testing methods, in Novell labs. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707261944.MAA02911>