On Thu, Sep 01, 2005 at 11:02:31AM -0400, Steven M. Bellovin wrote:
> Right, which raises questions about the linux emulation in the kernel.
> It's using /emul/linux as a pseudo-root or a pseudo-overlay, but it's 
> not doing the right thing.  Should it be changed to use more of the 
> real overlay file systems?

	I was thinking of doing something like that, where linux processes
would get automatically chroot'd into /emul/linux.  That'd need a
slightly different overlay file system that doesn't automatically
create directories.  I think I also ran into another issue wrt to
the behaviour of the overlay differing from syscall to syscall, but
looking at the compat code now it looks pretty consistent and I can't
remember what the exact issue was.

	Of course you'd still have the problem of how to refer to a non-emul
binary if a emul one exists at the same path.  The overlay/chroot would
need an escape path like "/../foo" works now, but that'd still run into
problems with realpath.  You could tweak that to "/.../foo" and do a null
mount of "/" on "/emul/linux/...", but null mounts on union mounts are
(again) broken at the moment (deadlock with procs in union_alloc/vnlock).


> It also raises the question of what, if anything, pkgsrc should do 
> differently.  Newer versions don't seem to create /usr/pkg/bin, so 
> maybe it's a non-issue for now.  If I'm wrong about that, should there 
> be a warning message with acoread7?  A shell script 'lpr' that would 
> just exec lpr, from the NetBSD environment instead?

	If acroread is actually calling the getcwd system call (like the
/emul/linux/bin/pwd binary does) then a quick fix might be to create a
emul specific version of that.

eric