Re: NFS4 mount problem

[Trond Myklebust <trond.myklebust@fys.uio.no>]

må den 18.04.2005 Klokka 11:34 (+0100) skreiv David Howells:
>  (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.

No. If you want generalized support for mounting NFS filesystems, then
the right thing to do is to create a userland library that can translate
the mount options, set up the binary structure with sane defaults etc.

Without such a library, it is pointless to contemplate "other callers".
With such a library, you will have a single point for switching between
32bit and 64 bit.

My concern is that we are slowly but surely building up a bigger
in-kernel library for parsing the binary structure than it would take to
parse the naked mount option string. There are only 2 reasons for doing
that parsing in userland:

  1) DNS lookups
  2) Keeping the kernel parsing code small

> > 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.

Then can we kill the PPC64 binary structure and substitute PPC32?

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html