lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: UID width
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.034 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site