> I think we should change __kernel_pid_t now that we are changing
> __kernel_uid_t.
I agree -- I also want to take a look at the padding and size of
other values passed to/from the kernel. I don't think we want to do
another ABI again anytime soon.
> 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.)
we can make libc5 work with in a 32-bit uid_t system, by being
careful. no amount of care will mkae most libc5 programs work with a
32-bit pid_t kernel after a period of time
> b) The reuse of pids causes security problems.
I don't think this is really an issue
> c) 32000 processes is not enough.
Right _now_ it is for most people, later on, there may be cases when
it is not. You need a big machine, 32K processes requires 256M of
non-swappable kernel memory. Ouch.
In reality, I don't know how well the scheduler will handle many
processes either.
> get_pid() {
> return ++last_pid;
> }
You have to be a little more careful than this. DaveM a while back
mentioned one of the sparc platforms can fork 10,000 times a second
(I think). This means you can wrap this in under a week...
> suffices. Even when reuse occurs, the current get_pid() will
> be much more efficient when a larger pid-space is available.
OK
> 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
Gover over 32-bits on x86 is _not_ a good idea, in fact, its a really
bad idea.
I think 32-bits with a lesser amount of reuse is acceptable.
What would be nice is to see 64-bit platforms have a 64-bit pid_t,
even if initially it does wrap and 2^32.
-cw
-
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:25 EST