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 <[EMAIL PROTECTED]> - 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
