Date: Thu, 12 Oct 1995 11:30:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: se@zpr.uni-koeln.de (Stefan Esser) Cc: erics@now.com, current@freebsd.org Subject: Re: cvs commit: src/sys/i386/ibcs2 ibcs2_ioctl.h ibcs2_ipc.h ibcs2_isc_syscall.h ibcs2_isc_sysent.c ... Message-ID: <199510121830.LAA15628@phaeton.artisoft.com> In-Reply-To: <199510121256.AA10533@Sysiphos> from "Stefan Esser" at Oct 12, 95 01:56:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
STefan writes: > On Oct 11, 20:07, Eric Siegerman wrote: > } Subject: Re: cvs commit: src/sys/i386/ibcs2 ibcs2_ioctl.h ibcs2_ipc.h ibcs > } On Oct 10, Stefan Esser wrote: > } > [...] if just a single > } > directory is searched (e.g. /compat/ibcs2/lib) a mount of a System V > } > /usr file system on /compat/ibcs2 would not be much use. There were > } > other directories that contain shared libraries under 386/ix at least > } > (I never had to work on a SCO system) > } > } FYI, Xenix 2.3.4 has a shared library in /shlib/libc_s. > > Thanks for the information! > > It seems to strengthen my point, that > mounting a System V file system under > /compat/ibcs2 and using its bin and lib > directories will not work in general ... > > We'll need to play tricks (e.g. with > symlinks) to make the shared libraries > appear at the place where the emulation > code looks for them, and then I'd rather > choose a file system, that is suitable to > take a copy of those libs, in case I need > to install them ... With respect, this does not strengthen your argument. The NetBSD (FreeBSD -current) code operates by causing lookups to occur in the subtree as if it were the root before occurring in the actual root for lookups for binaries (actually, this could be made more general, but would require about 200 lines of changes to kern/vfs_lookup.c and all code calling namei() to use preparsed path component lists). What this means is that it doesn't matter where the root directory starts, as long as it starts somewhere. Effectively, each lookup occurs first in a chrooted environment, then in a non-chrooted environment if an emulation specific copy has not been found. So your argument, based on the premise that the loader itself was being hacked for the emulations, is incorrect. Mounting at various locations will, in fact, work, as long as the relative root is known to the exec loader and the system call entry translation functions of an exec loader. Regards, 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?199510121830.LAA15628>