Followup to: <Pine.GSO.4.10.10005262057120.17448-100000@weyl.math.psu.edu>
By author: Alexander Viro <viro@math.psu.edu>
In newsgroup: linux.dev.kernel
>
> 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.
>
Indeed. dev_t *NEEDS* to change in the next major cycle, PERIOD. For
reasons previously discussed, this will probably be a 64-bit type
split 32:32. That way you don't need the scheme above -- you will
have *plenty* of space to encode anonymous device numbers in any way
you please. However, I don't really think you're winning anything
with your type scenario. We need a larger dev_t anyway, and this is
just one instance of this.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot."- 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 : Sat May 27 2000 - 01:39:08 EDT