Date: Thu, 23 May 1996 13:30:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jehamby@hamby1.lightside.net (Jake Hamby) Cc: sos@FreeBSD.org, current@FreeBSD.org Subject: Re: Can't run Linux static ELF binaries? Message-ID: <199605232030.NAA08230@phaeton.artisoft.com> In-Reply-To: <199605231312.GAA00518@hamby1.lightside.net> from "Jake Hamby" at May 23, 96 06:12:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As a kludge, may I suggest that files within the /compat/linux > directory be assumed to be Linux/ELF, and files in /compat/svr4 > be assumed SVR4? Looks like the only statically linked programs > are stuff like ldconfig anyway, which you would want to install > in /compat so as not to conflict with FreeBSD's. A "proper" implementation of an ELF ld.so has it mapping into the memory hole above the 4k 0 page but below the actual program load address (this is, I am convinced, why the SVR4 EABI mandates a high load address. In that event, you can't use the ld.so name in order to get the binary type, even on shared images. You are putting off dealing with the inevitable. As to looking for /compat/xxx directory traversal, there is no way iterate a flag down on lookup as a result of lookup; otherwise, you could easily support forks using POSIX namespace escapes. I have some experimental mods for this, but they significantly impact the lookup mechanism in kern/vfs_lookup.c and in ecery one of the FS specific xxx_lookup routines for namei() processing; the biggest problem is the way the vnode locking is handled as a form of non-counting lock, making relookup() necessary in the first place. The changes are *way* above and beyond the FS changes I submitted; they are intended for support of extended attributes, resource forks and alternate directory name spaces (ie: Unicode file name support). They would incidently allow a flag to propagate down following a lookup without needing it to really be a namespace selector; thus when you traversed the point, the flag would be set, the traversal could complete, and the flag would remain set. It would be more correct (and elegant) to attach an ELF segment identifying the binary type by machine to Linux and FreeBSD binaries... or better, to add a system interface ident to the ELF format (yes, this would be a real format change) that can be ignored by systems that don't support it, but which the GNU tools would produce and set a prereserved flag type for Solaris and UnixWare, seperately. Then hope that Sun and SCO adopted the enhancement, but assuming Sun or SCO if nothing was present. Sean has more input on all of this. 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?199605232030.NAA08230>