Background:
When running a Linux binary in Linux compat mode, all calls to open(),
readdir() and such, end up calling linux_emul_find() from linux_util.c.
This functions looks for a directory/file with the same name in the
/compat/linux hierarchy.
The net effect is that there is no way to, for instance, back up the
real /usr from Tivoli, etc... as there is no way to get to a real path
if there is anything with the same name inside /compat/linux.
I'd like to understand if there is any accepted way to work around this
limitation (no, symlinks are not an option :-p), I'm sure not.
Proposal:
Implement some way to make this behavior user configurable. The easiest
way would probably involve a sysctl to turn it on/off but I would like
to have more granularity. I could probably store a flag somewhere in
elfhints_hdr.spare, but I'm sure there will be a lot of objections to
this.
I think this could be done in two parts:
1 - A flag to turn path transalation on/off
2 - A version of the syscalls which accept this flag
3 - A shared library implementing just the needed function calls and
calling the new syscalls
I don't know if I even understand this correctly, never done this
before, but I could learn ;-)
Another approach would be to somehow teach the kernel which processes
to "let alone", but this would be tricky and probably slower.
Alternate proposal:
If everything else fails, what about mapping the real filesystems
somewhere below /compat/linux? Something like:
/compat/linux/native/root
/compat/linux/native/usr
/compat/linux/native/var
Actually (I'm thinking about this just as I am writing) this could
be the easier and cleaner solution. Note that these must appear to
be real mountpoints. Does this need to go through userland NFS?
So, let the discussion begin. If there is no interest, I will
implement it in the way which is easier to me (which probably
would be the last one). If there is interest and anybody
volunteers, fine, otherwise I will implement it and put it up
somewhere for review.
Bye,
Andrea
--
Secret hacker rule #11: hackers read manuals.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
