Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: UID width | Date | Fri, 8 Jan 1999 21:38:19 -0500 (EST) |
| |
Chris Wedgwood writes: > On Fri, Jan 08, 1999 at 04:45:02AM -0500, Albert D. Cahalan wrote:
>> 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
Even for libc 5, Debian used a private copy of the kernel headers. For continued libc 5 use, just keep the Linux 2.2 headers.
>> 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).
Ugh. With smbfs being _very_ common, it would be nice to be able to directly share UID values.
(just that facts -- don't ever let M$ hatred ruin your judgement)
>> 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'.
If you have so many devices that it is hard to deal with them, you really ought to be using devfs.
>> 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.
This is surprisingly important. Modern filesystems can use part of the inode number as a hash value or volume index. SGI's XFS is one such filesystem. Reiserfs would be another. UDF would work better with 48-bit inode numbers, including the volume number. You are not likely to need more than 2**32 inodes, but the address space is great.
If 128 bits is tolerable, Coda files could be uniquely addressed.
>> 64 off_t > > I think we already have this
I doubt it:
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #define p(t) printf("%d "###t##"\n", sizeof(t)) int main(int argc, char *argv[]){ p(char); p(short); p(int); p(long); p(ssize_t); p(size_t); p(off_t); p(uid_t); p(gid_t); p(pid_t); p(dev_t); return 0; }
on a 32-bit glibc system produces (notes added)
1 char 2 short 4 int 4 long expected :-( 4 ssize_t ouch 4 size_t ouch 4 off_t ouch 4 uid_t OK! 4 gid_t OK! 4 pid_t OK! 8 dev_t why?
- 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/
| |