Subject: Re: printing with acroread7 and cups
To: Steven M. Bellovin <email@example.com>
From: Eric Haszlakiewicz <firstname.lastname@example.org>
Date: 09/01/2005 11:30:50
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.