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>