On Wed, 2010-12-01 at 22:13 -0500, Trond Myklebust wrote: > I'm suggesting it should rather match the compat_ulong_t, since that is > what 64-bit kernels will need to deal with if running a 32-bit > userspace. For 64-bit kernels that have no 32-bit userspace emulation > layer, why would we care about returning a truncated 32-bit fileid? > > Conversely, if running a 32-bit kernel, then 'unsigned long' will > directly match the types used by fs/readdir.c:filldir() Ah, got it now... Sorry for denseness... Hmm, what would be ideal is for nfs_compat_user_ino64() to know if it's value will be passed to compat_filldir or filldir. If we use compat_ulong_t when CONFIG_COMPAT is defined, and enable_ino64 = 0, it will always reduce the fileid to 32 bits, even if being passed to filldir on a 64 bit machine which is prepared to take a 64 bit fileid. On the other hand, if enable_ino64 = 1, then fileids >= 2^32 will cause an error if a 32 bit user space application is being invoked. With enable_ino64 = 1 on a machine otherwise enabled for 64 bit inode numbers, it will definitely work like any local file system with 64 bit inode numebers. With enable_ino64 = 0, it will always force fileid into 32 bits if there is any 32 bit user space, which I suppose is good behavior. I will submit a revised patch. Thanks Frank -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
