I think the topic has had some recent discussion -- like one or two
months ago.
There are three problems:
- userspace 16/32 bit UIDs
- kernelspace 16/32 bit UIDs
- user/kernel interface
To avoid an extremely unpleasant piecemal shifting from limited value-
spaces to less limited ones, I would suggest that in 2.3 we will do
a large-scale overhaul of the interfaces to do 32-bit UIDs/GIDs, and
64-bit file offsets. I am sure there are also some other similar
issues lurking around. (a bit more on this below.)
No, it won't happen in 2.2 for i386. Alpha has 32-bit UIDs, but
that is mostly because of ABI compability with DEC UNIX, which has
32-bit UIDs..
The overall UID-size list is:
alpha u32
arm u16
i386 u16
m68k u16
mips s32 (?)
ppc u32
sparc u16
sparc64 u32
Comparing i386 vs. Alpha /usr/src/linux/include/asm-*/posix_types.h files
shows at least following items to have size questions:
dev_t u16 u32 /* Need someday u64 ? */
mode_t u16 u32 /* no need to change ?*/
nlink_t u16 u32 /* no need to change ?*/
ipc_pid_t u16 s32 /* no need to change ?*/
uid_t u16 u32
gid_t u16 u32
off_t s32 s64
size_t u32 u64
ssize_t s32 s64
__kernel_loff_t s64 s64 /* already usefull size */
Some people are asking support for things like 100 000 processes,
while the current code inside kernel/fork.c does lots of assumptions
about limit being 32 000 processes, so:
pid_t s32 s32 /* Need someday s64 ? */
but that will require user-space tools modified a bit, too.
(Things like 'ps' and 'gdb' commands, to name a few.)
> Just for grins, I tried changing the typedef in linux/types.h and
> recompiling the kernel. Wouldn't even boot. Then I noticed that the
> uid and gid fields in ext2 inodes are 16 bits. So it seems like this is
> a project, not than a hack. (This was on 2.0.35.)
Depends what you mean with 'boot', or starting user-space
programs, like '/sbin/init' ?
Extending EXT2 fs uid-spaces is trivial, once the interface
issues to user-space are resolved (and all new binaries are
in use which use 32-bit uids..)
> There's enough interest in this on campus that we can throw some
> resources at it. If no one else has this one, we could probably do it.
> If someone is doing it, how do I get in touch? Comments? Advice
You will need to do magics into glibc-2.0.100+ to support
it, possibly implement sysconf(2) into i386 to allow easier
way for the library to find out if the kernel supports larger
uid_t value scope, than that of the classical default.
There are lots of calls which pass around uids and gids (as
parameter values, or components of a struct), all those will
need at least two alternate forms.. (Alternate call vectors?)
You could (perhaps) do it even via personality() syscall.
See values/flags from <linux/personality.h>.
(How do you do the backwards compability, that is the crux..)
> Regards,
> Jon
> ----------------------------------------------------------------------
> Jon Leonard jbwl@umich.edu
> CycleStealer, School of Information, Umich +1 (734) 936-7255
/Matti Aarnio <matti.aarnio@sonera.fi>
-
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/