On Fri, 26 May 2000, David S. Miller wrote:
> Date: Fri, 26 May 2000 20:46:24 -0400 (EDT)
> From: Alexander Viro <viro@math.psu.edu>
>
> I'm afraid that you will find it rather hard to patch - kernel
> itself couldn't care less (i_nlink can be made unsigned int - not a
> big deal), but you'll have to deal with the userland. On x86 struct
> stat as returned by the kernel contains 16-bit st_nlink and you'll
> have to
>
> Alexander, if I'm not mistaken, glibc uses a 32-bit field in what it
> exports to userspace already, and it is translated between the kernel
> and userland structure precisely because of these kinds of issues.
Yup. Which is precisely what I said - 3 new syscalls + teaching glibc to
use them + recompiling the statically linked stuff.
> If the kernel syscalls are addded, glibc just is taught to check for
> the new syscalls, and then adjust it's struct conversion code
> accordingly.
>
> The net result is that userland apps are using a 32-bit field
> and they will thus get things right if the kernel starts to provide a
> 32-bit value.
Exactly - the kernel side is (mostly - you'll need to teach the old
syscalls that 65536 should become 65535, not 0) trivial, the problems are
a) yet another ABI change
b) yet more *stat() syscalls.
Look: there are other good reasons to change struct stat and I'm not too
happy about doing it in $BIGNUM steps, each resulting in new triple of
syscalls. If we are going to do that at all we'ld better do it at once.
PS: I still want to add u16 fstype in addition to dev and let glibc
combine them into st_dev if it wants; internally we'ld set the fstype to
filesystem type and make dev unique _for_ _given_ _type_. For normal
filesystems we can very well retain device number, for NFS and friends
we'ld get 16-bit number per type and that would kill the fscking
"anonymous" devices/255 non-dev mounts limit. Again, there _are_ reasons
to change struct stat, but we'ld better collect these changes and do them
in one step.
-
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:16 EST