Hans:
As far as I can see, st_nlink in struct stat64 is defined to a 32-bit type
on all Linux architectures.
Starting with glibc 2.2, the old stat() system calls are deprecated and
glibc will always use stat64(), even if you aren't compiling for large
file support. This is necessary to use 32-bit UIDs.
If glibc 2.2 isn't released for a while, it's possible that glibc 2.1
might also adopt this behavior. (We're using such a version of glibc 2.1
here in order to take advantage of 32-bit UIDs.)
The glibc user ABI for struct stat has always used a 32-bit type for
st_nlink, so no recompiles should be necessary (unless some program
intentionally used a <32 bit type for an internal variable which holds
st_nlink).
So at least from the kernel-user ABI point of view, it should be safe to
allow >65535 st_nlink.
We'd have to decide the best safe way to truncate the value for the older
stat() syscalls, and we'd have to make sure that it doesn't break
filesystems that can't handle >65535 links (I'm not familiar enough with
the VFS to know whether or not this would be a problem).
-Chris Wing
wingc@engin.umich.edu
-
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 : Wed May 31 2000 - 21:00:19 EST