Messages in this thread | | | Date | Fri, 14 Jan 2000 09:02:27 +1300 | From | Chris Wedgwood <> | Subject | Re: Linux 2.3.39 has 32bit uid. What about 32bit pid? |
| |
> 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/
| |