Subject: Re: pid limit (Was: Re: Kernel support for ELF-format core files)
To: gabriel rosenkoetter <email@example.com>
From: Jaromir Dolecek <firstname.lastname@example.org>
Date: 01/24/2002 21:02:22
gabriel rosenkoetter wrote:
> Then that userland code is just silly. We provide pid_t for a good
> reason. If it can't ever break four digits, why are we wasting 32
> bits on it?
Well, int is more efficient to work with than short anyway :)
I think that the limit should be bumped to SHRT_MAX-1 (and NO_PID
== SHRT_MAX), but not more.
- we need to support 16bit pids for some of our emulations. It's
prolly possible to map 32bit pids to 16bit, but it'd be ugly
- quite a few applications use short for the data. If a pid is more than
SHRT_MAX, it would appear as negative in them, causing unpredicable
- there may be assumptions about maximum number of active
processes in kernel code, shifting that limit too much might expose us
to some DoS attacks
Currently, IMHO it's not worth the efford to bump the process limit
more than noted above.
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-= Those who would give up liberty for a little temporary safety deserve =-
-= neither liberty nor safety, and will lose both. -- Benjamin Franklin =-