In article <20040709233320.37ed7187.cube@NetBSD.org>,
Quentin Garnier <cube@NetBSD.org> 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
>there.
>
>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/libc.so (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.
>
>Opinions?

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

christos