lkml.org 
[lkml]   [1998]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: High UID support for Linux
Date
Matti Aarnio writes ("Re: High UID support for Linux"):
> > That's why I want 16 bit uid to 32 bit uids to be a planned change,
> > rather than for it to be flag day for Linux where everyone has to
> > throw away all their existing code.
>
> If your runtime environment has only 16-bit UIDs, use of
> old binaries via old syscalls will continue as before
> *without any changes*.

I don't see why I should have to recompile code for programs that
aren't interested in uids, but happen to use them purely because
braindamaged Unix APIs.

> If you want to operate in the extended universe, *then* you
> need to move into the lattest and greatest stuff which uses
> extended valuespace syscalls, but for majority of the people

I don't mind upgrading the system programs - I expect that and
upgrading a Linux system is usually fairly hassle free.

However, locating and fixing programs that will be affected when given
a large uid is a massive task. I don't control the users' code, I
don't control all the installed applications, and I don't control any
of the commercial applications. Some vendors are refusing to ship code
for glibc2 on the grounds that its yet another platform to support.
Given that most applications don't really care about uids, this
problem can easily be worked around. Only those applications that
genuinely use uids should be forced to break.

> > Peter, who's just discovered the joys of compiling code which mixes
> > libraries compiled with gcc 2.8 and gcc 2.7.
>
> C++ ?

I believe that it's related to the handling of C++ constructors and
destructors, although the neither the program nor libraries contain
any C++ code.

Peter

-
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:45    [from the cache]
©2003-2011 Jasper Spaans