>We already have compat_sys_mount that treats the mount data for smbfs and >ncpfs specially, so you could you add an nsfv4 specific bit there?
Do we really want to pile filesystem-type-specific stuff into fs/compat.c? It's bad enough that it's there for smbfs and ncpfs (and similar stuff for NFS server). It's only going to get worse. fs/compat.c is fine for interfaces implemented by fs/ code, but the 32/64 bit translations for other interfaces ought to be done by the modules that know those interfaces. A mount option structure that contains addresses should contain information as to whether it's in 32-bit-address format or 64-bit-address format. The nfsv4 read_super method can use that to translate its own mount options. Another option would be for Linux to pass that information (essentially, whether the mount() system call is being handled by sys_mount() or compat_sys_mount() as another argument to read_super. This would allow better backward compatibility with user space binaries, if there are already 32 bit and 64bit binaries using indistinguishable mount option structures. The same issue, by the way, applies to ioctls, some of which have an argument which is the address of a block of memory that contains other addresses. fs/compat.c approaches these in a more filesystem-type-independent way than it does mount(), but still not independent enough. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - 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
