>>>>> On Thu, 16 Oct 2003 09:40:28 +1000, Neil Brown <neilb@cse.unsw.edu.au> said: >> So it looks to me like exportfs supports only 32-bit ino_t? Neil> Looks can be deceiving (especially when those /* */ operators Neil> haven't been used correctly). Neil> get_object is part of the legacy support in exportfs, where Neil> legacy really means ext2/ext3. Any filesystem that actually Neil> used 64bit inode numbers would need to define it's own Neil> export_operations->get_dentry function which can interpret the Neil> file handle however it likes, including using 64 bits of it Neil> for an inode number (though such a filesystem probably Neil> wouldn't work with NFSv2, but that's OK). Ah, that sounds good then. >> (Neil, to give you some background: we'd like to change ino_t on >> ia64 from 32 to 64 bits and found that the only potential ABI >> issue is due to NFS; "struct nfsctl_export" is definitely an >> issue, but perhaps we can live with that. I'm less certain about >> any issues exportfs might have.) Neil> ex_ino in nfsctl_export is not actually used, so all that is Neil> needed is to make sure user_space and kernel_space agree on Neil> the side of the field. Maybe a __kernel_old_ino_t or Neil> soemthing. But I would be quite happy to #ifdef out that Neil> system call for ia64 if that was preferred. Neil> So in short: there is no big problem, and the small problem is Neil> largely one of aesthetics. OK, perhaps for now you could use Nathan's #ifdef __ia64__? Something along the lines of __kernel_old_ino_t certainly would be cleaner, if other arches need something similar. --daviad - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Oct 15 21:22:38 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:19 EST