Petr Vandrovec:
> but some (two) of these structures include also __kernel_pid_t.
> So I'd like to ask, whether we are going to 32bit pid_t in 2.3.
Alan:
> Probably not. Let me ask a related question - are you going to miss 2 bytes of
> padding in case ? I'd use 32bits in case.
I think we should change __kernel_pid_t now that we are changing __kernel_uid_t.
a) It is easy - easier than the change to larger uid.
Roughly speaking the only change is in the ipc structs.
(The other part of the change is in /proc.)
b) The reuse of pids causes security problems.
c) 32000 processes is not enough.
d) There is a speed advantage:
Right now when a process is spawned we have to find a pid for it,
and with a few thousand threads a significant part of the 32000
pids allowed today will be in use, so that often get_pid() will
have to walk the entire task list. If we are sure that a pid is
never reused, then
get_pid() {
return ++last_pid;
}
suffices. Even when reuse occurs, the current get_pid() will
be much more efficient when a larger pid-space is available.
(On the other hand, if we do not enlarge the pid_t size, then
a bitmap with pids_in_use would make get_pid() much faster.)
In fact, I like high uptimes, and a system in which the same pid is never
used again. But this means that 32 bits may not be enough. That again
means that I would like to see padding in places like
struct msqid64_ds {
...
__kernel_pid_t msg_lspid; /* pid of last msgsnd */
__kernel_pid_t msg_lrpid; /* last receive pid */
unsigned long __unused4;
unsigned long __unused5;
};
that is, I would prefer to see there
__kernel_pid_t msg_lspid; /* pid of last msgsnd */
unsigned long __unused4;
__kernel_pid_t msg_lrpid; /* last receive pid */
unsigned long __unused5;
so that it will be easier to go to 64-bit pids twelve years from now.
Andries
[I may still have some usable patch fragments for getpid and family.]
-
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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:22 EST