From owner-freebsd-hackers Fri Mar 1 14:10:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14289 for hackers-outgoing; Fri, 1 Mar 1996 14:10:58 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA14282 for ; Fri, 1 Mar 1996 14:10:54 -0800 (PST) Received: by Sysiphos id AA06940 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Fri, 1 Mar 1996 23:10:47 +0100 Message-Id: <199603012210.AA06940@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 1 Mar 1996 23:10:47 +0100 In-Reply-To: Jake Hamby "Re: Quake's out, where's that Linux ELF emulation?" (Feb 28, 14:25) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jake Hamby Subject: Re: Quake's out, where's that Linux ELF emulation? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Feb 28, 14:25, Jake Hamby wrote: } Subject: Re: Quake's out, where's that Linux ELF emulation? } Well, certainly being able to run the Linux version is better than no } version at all, right? Also, if our Linux ABI is reasonably efficient } (as it seems to be), then would there be any significant further gain to } make a "native" port? For many applications, it seems unlikely. After Well, if we have to run dynamically linked Linux binaries anyway, then we'd better start linking against Linux shared libraries ourselves ;-) } all, we're just patching Linux system calls through to our kernel, it's } not as if we actually have to go user their crummy KERNEL (although we do } have to use their shared libraries...). Exactly. And those will take away precious RAM pages in my system, for identical functionality as provided by the FreeBSD libraries. (And it may amount to several MB total, if native and Linux X11 binaries are used simultanously ...) It's the same situation, that causes Linux to need more RAM, if both a.out and ELF applications are used. But we always managed to avoid this ... } Anyway, I agree with Jordan on this, better to work on the ELF support in } FreeBSD then tell vendors, "Oh by the way, the Linux version of your } program works GREAT on FreeBSD, why don't you advertise it as } FreeBSD-compatible too (and maybe think about doing a native port for your } next version)?" :-) Well, there won't be FreeBSD support then, because it is too expensive for the vendor to support another platform. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se