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.

Three reasons:
- 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
  results.
- 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
-- 
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  =-