Subject: Re: emul vs. symlinks
To: None <>
From: Christos Zoulas <>
List: tech-kern
Date: 07/10/2004 01:24:57
In article <>,
Quentin Garnier <> wrote:
>Hi folks,
>There is an issue with the way the emulation layer works with symlinks.
>When opening a file or looking for an interpreter, the emul_find()
>function is usually called, and its main purpose is to try and find a file
>in the emulation root and failback on the real root if it isn't found
>It doesn't work well with symlinks since that part is completely handled
>by namei(), which doesn't know, and therefore ignore, the emulation root.
>The result is that absolute symlinks are always treated relatively to the
>real root, which has some side effects, notably in netbsd32 since we
>switched to a dynamic root:  /usr/lib/ (and friends) and
>/usr/libexec/ld.elf_so are symlinks to their counterpart in /lib and
>/libexec, and an infortunate choice was made to use absolute symlinks.
>That makes it impossible to use 32 bits binaries in a 64 bits system the
>same way we use Linux binaries on i386 (Linux uses relative symlinks for
>the lib stuff, so the issue never really arose).
>My proposal is to add a function in sys/compat/compat_util.c that is a
>complete rip-off of namei(), but customised to emul_find()'s needs.  It
>actually needs two things:  to use the emulation root in the resolution
>process to try and find a file inside that root first, but still fallback
>on the real root.  Then, it also needs a path to found file, since the
>actual resolution will happen later using the real namei().
>So far it works fairly well, I have quickly tested it but not thoroughly.
>I have commented all the differences with the real namei(), so report to
>the code for details.

I think that keeping two copies of namei is a bit ugly. Why don't we make
relative symlinks?