Re: QUESTION: 32-bit UIDs and Linux 2.3

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Fri, 9 Jul 1999 11:19:51 +0200

On Thu, Jul 08, 1999 at 11:29:53PM -0400, Chris Wing wrote:
> Hi. I just sent a message to linux-kernel about a patch I wrote to enable
> the use of 32-bit UIDs with Linux 2.0 and Linux 2.2. I'm curious what
> other people think about getting 32-bit UID support into the 'official'
> kernel, i.e. Linux 2.3.
>
> In my patch against Linux 2.2, I've tried to do everything in a 'nice'
> way: both the new 32-bit UID system calls and the old 16-bit backwards
> compatibility system calls are config options, so that you can compile a
> kernel with one or both enabled. The system calls that need to return
> 16-bit uids/gids to old programs do so via a macro, high2lowuid(), that
> returns a fixed value in lieu of uid mod 65536.
>
> I'm interested in what people think of the approach in my patch, i.e. does
> it fall under the category of:
>
> o Perfect - it does everything the way you wanted.
>
> o Some issues - i.e. my handling of IPC semctl(), msgctl(), and shmctl(),
> ext2 changes should be removed and wait for later, etc.

I'm uneasy with your stat(2) modification.
I think when you change the meaning of field values, you should tell the C
library about it. glibc could do ugly tricks, like trying getuid32 syscall
first and if it returned error, it would know the kernel does not support
the new st_uid/st_gid fields, but that costs you a syscall for the common
case in the future where both glibc and kernel will have large uids/LFS and
stuff like that.
So I'd propose creating stat64, lstat64, fstat64 system calls for all the
platforms which need it and carefuly lay out the new structures, so that
they will hold LFS values, large device numbers, large uids etc.
I wonder whether we are going to use 32bit or 64bit dev_t, because right now
I can still change it for sparc64 in the stat structure (all fields are LFS
capable but dev_t is right now 32bit there), after one month or two I'd have
to add new syscall like it will be needed on all 32bit ports.

>
> o Completely 100% incorrect- I should go bury my patch in the litter box
>
>
> How much backwards compatibility do you think there should be:
>
> o Support all old binaries and make things as nice as possible, never
> return 0 instead of 65536 (this is what my patch does)

Your glibc patch should care about binary compatibility and let all possible
combinations to work (old vs. new kernel and old vs. new glibc). So, I'd
propose not to change names of the old syscalls, it will just create severe
confusion for glibc maintainers, rather name the new syscalls differently.
>
> - why is the system call table for sparc populated in a 'sparse'
> manner? is this to locate things on the same cache line, etc?

Historical reasons, it was first a copy of the SunOS syscall table I think
and then split from that, so the identical syscalls between SunOS and Linux
have usually the same syscall number.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.10 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

-
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/