> At some point in the future we might also want 32-bit dev_t and
> 32-bit pid_t so its probably worth trying to do them all at once,
> that way we don't end up with 15 different flavours of the same
> system calls (think about stat et al and all the combinations of
> short/long system calls... yuck).
>
> One problem I have in doing this, is some of the glibc IPC structures
> assume 16-bit pid_t -- which IMO is damned silly.
Somebody is on drugs. They made dev_t 64-bit and left pid_t 16-bit.
They also left size_t 32-bit AFAIK, so the 2 GB file limit stays.
Since glibc will have to use new symbols for everything anyway,
current sizes can be fully ignored.
What we might want:
32 uid_t For distributed authority, 128 is better.
32 gid_t same as above
32 dev_t
64 ino_t Coda and Reiserfs could make good use of 128.
64 off_t
I don't believe gcc supports "long long long" yet. Should it?
Anything left 16-bit can become 32-bit just for access speed.
> Anyhow, if anyone wants to lend a hand here, it would be most
> appreciated -- please contact me off the list. There are library
> issues that also need to be resolved, and various user-land tools
> need fixing so as not to introduce security problems.
>
> Oh, and please don't tell me about not every needing more than a
> 16-bit pid_t -- mingo has already posted patches (twice) to make this
> possible, even though its presently not terribly practical...
Going up to 99999 should "only" break binary compatibility.
Past that, all sorts of tools run out of screen space and die.
Well... procps has an error message for such numbers.
Let me know if and when you need that changed.
-
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/