Date: Wed, 4 Nov 1998 14:53:37 +0100 From: Martin Cracauer <cracauer@cons.org> To: Terry Lambert <tlambert@primenet.com>, Bill/Carolyn Pechter <pechter@shell.monmouth.com> Cc: jkh@time.cdrom.com, freebsd-advocacy@FreeBSD.ORG Subject: Re: On advocating FreeBSD and the Halloween memo... Message-ID: <19981104145337.A25068@cons.org> In-Reply-To: <199811031835.LAA01373@usr05.primenet.com>; from Terry Lambert on Tue, Nov 03, 1998 at 06:35:20PM %2B0000 References: <199811031724.MAA28109@shell.monmouth.com> <199811031835.LAA01373@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'd like to second the opinion that strong emulation of other OSes is a key point for FreeBSD and that the current level is already much better than we expected it could even become, so why stop here? :) In <199811031835.LAA01373@usr05.primenet.com>, Terry Lambert wrote: > I think FreeBSD should move toward IABI and Solaris binary > compatability in the default OS, changing system calls and > manifest constant values, as necessary, to achieve this. > > That will get you your applications the fastest. Why is that better than a syscall emulator? The obvious advantage is that you can use their shared and static libraries in FreeBSD binaries. But to do so, you would also have to change all of libc in the same way, wouldn't you? If you invented a clever scheme to link a shared - say - Solaris Library against a Solaris libc until everything but syscalls have been pulled into and then link the combination thereof against your FreeBSD object files and libc, you would have a lot of double code, with possible bookkeeping problems in things like malloc/free, so the automatic way can't possibly work. What about wrapper calls around the FreeBSD libc? solaris_objects --> wrapper -+ | freebsd_objects -------------+--> FreeBSD libc You would link all Solaris objects together, put in the wrapper that resolves all incompatible calls on the Solaris objct's side and maps the calls to adapapted calls to functions with possibly the same name on the other side (the FreeBSD side that is used to produce an executable). So, for further linking you just pull in just one big block (Solaris objects and wrapper) and you can be sure that this blocks expects the FreeBSD interface for every symbol it wants resolved. Of course, that requires the same research we do for system calls to be done for all libraries. Given that tracing userlevel library calls is a lot more difficult (since you can't trace them as easily as system calls) and therefore is a lot easier to do for Linux. This will probably fail for thread programs that use native Solaris thread interfaces, since we presumely don't copy their way of sheduling userlevel threads on kernel threads, but programs that just use the Posix calls are save since we resolve the Posix thread calls in userlevel. The question here is how many binary-only software providers care to restruct themself to standard interfaces :-( You can add a /dev compatiblity feature to the TODO. /compat/linux/dev/audio may want to talk a different interface. I won't even start talking about STREAMS or anything networking-related that uses /dev entries. Linux would be a lot easier here, since Software vendors have to use some sane way to construct packets. BTW, where can I see/buy a copy of the SystemV/Intel binary standards? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ 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?19981104145337.A25068>