> Somebody is on drugs. They made dev_t 64-bit and left pid_t 16-bit.
Indeed... damned silly IMO -- and possibly to late to fix it[*].
> They also left size_t 32-bit AFAIK, so the 2 GB file limit stays.
No -- we can have 64-bit off_t and use the 64-bit APIs.
> Since glibc will have to use new symbols for everything anyway,
> current sizes can be fully ignored.
Not entirerly -- we can't break libc5 straight away -- and what the
kernel provides us retricts what glibc can do. If the kernel only
supports 16-bit pid_t -- glibc can only support 16-bit pid_t
> 32 uid_t For distributed authority, 128 is better.
32-bits is enough. Distributed authority can be done is userspace
with some kind of NIS mapping (presumably is a similar way samba can
map uid/gid values to the NT equivalents).
> 32 gid_t same as above
> 32 dev_t
Might want this bugger -- 64 should suffice. This way we can carve up
the 64-bits and give each section `meaning'.
> 64 ino_t Coda and Reiserfs could make good use of 128.
Arguably either way. I think probably we do need this, I'm not sure
how practical more than 2^32 inodes is, but in theory it diable even
now.
> 64 off_t
I think we already have this
> I don't believe gcc supports "long long long" yet. Should it?
no -- why? x86 long long code is bad enough (someone else posted
something refuting this, but I still say long long sucks in practise,
for example 5 such variables used interchangably in a function).
> Anything left 16-bit can become 32-bit just for access speed.
Not quite... we have to thunk certain values though. For example, in
the case of uid's, 0xFFFE -> 0x0000FFFE but 0xFFFF -> 0xFFFFFFFF.
> Going up to 99999 should "only" break binary compatibility. Past
> that, all sorts of tools run out of screen space and die.
They can be fixed -- top has been fixed many times already.
-cw
-
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/