>>>>> " " == kernel <kernel@kvack.org> writes:
> LFS doesn't require that ino64_t be 64 bits. Even so, the
> stat64 structure has enough space for us to put a 64 bit inode
> number in (__unused[12]). That leaves the compatibility
> problem that going to a 64 bit ino_t raises: all of the old
> stat routines would have to be deprecated and removed from the
> kernel since there is no reasonable way to map a 64 bit inode
> number into an old stat structure. Now is not the time to
> create that mess.
The mess is already there: Under NFSv3 I already have to hack 64-bit
inode numbers into 32-bit quantities. It would be nice to be able to
serve the full 64-bits to those programs that need it. XFS also will
need this I believe.
Nevertheless, if the structure is extendible then we can defer it. The
only problem then is that you can't test for sys_stat64 and assume
that all is groovy. You will additionally have to test for 'do we have
kernel version blah which supports ino64_t in __unused[0-8]'?
> st_blocks has the space for its high 32 bits reserved as well,
> but keep in mind that a 32 bit kernel does not support block
> numbers > 32 bits at present, so it really isn't a limit. In
> fact, glibc expects st_blocks to be a long long, which is why
> the high bits are zeroed (just the high bits are reserved for
> the file times). It's 100% doable today, just waiting for the
> need.
This I'll admit is not actually needed at the moment (XFS?), so we can
probably defer this.
>> We're also still missing some LFS functions such as
>> getdents64() / readdir64(). That's less worrying since we can
>> always come back to those for 2.5.x or whenever...
> getdents64/readdir64 are nothing but a means of Doing Things
> Slower as no filesystem in the kernel requires a 64 bit
> directory offset (or inode number -- see above). For that
> matter, if we did require a 64 bit directory offset, then we
> wouldn't be able to use the old getdents/readdir calls on such
> a filesystem. If we're going to throw binary compatibility
> completely out the window, then there are lots of things in the
> ABI that need fixing.
Again: see NFSv3... Whether or not Linux likes and uses 64-bit
directory cookies, IRIX servers do. Again it's on my wishlist for
'sometime in the near future'.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:21 EST