Re: IA64 ino_t incorrectly sized?

From: David Mosberger <>
Date: 2003-10-16 11:20:25
>>>>> On Thu, 16 Oct 2003 09:40:28 +1000, Neil Brown <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Wed Oct 15 21:22:38 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:19 EST