On 10 Jun 2000, Trond Myklebust wrote:
> You'll note however that we're not yet ready to comply to the full LFS
> standard.
>
> In particular, things like 64-bit inode numbers, 64 bit block sizes,
> are missing from our sys_*64() API.
> That's a bit worrying IMHO, since it will make it harder to get back
> to these things at some future time with the stat64 etc. structures
> fixed in stone.
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.
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.
> 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.
-ben
-
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