Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > We've come across an interesting problem with NFS4 mount on a PPC64 box. If
> > the mount program is compiled as PPC32, then the mount() syscall is returned
> > EFAULT.
>
> So, why is this not a case of "Doctor it hurts..."?
Because:
(1) The kernel is returning EFAULT to the 32-bit userspace; this implies that
userspace is handing over a bad address. It isn't, the kernel is
malfunctioning as it stands.
(2) The kernel API does not prohibit 32-bit userspace calling mount() under a
64-bit kernel. All other filesystems cope with it (AFAIK), so NFS4 must
too.
Either the kernel should return ENOSYS for any 32-bit mount on a 64-bit kernel
or it must support it fully. I think the latter is the right thing to do;
despite what you'd prefer, there are other callers of the mount syscall out
there.
> There should therefore be exactly ONE instance of usage, and that is in
> the "mount" program itself.
Exactly. That should then be the ppc32 mount; which should work equally well
with a ppc32 or a ppc64 kernel.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
