Re: Call for testers: New PID allocator patch for -CURRENT

[ ... dropping -hackers and leaving -current in ... ]

Peter Jeremy wrote:
> Note that many system utilities "know" that pids can be represented
> in 5 digits and having max_pid exceed 99999 will disrupt output from
> top, ps, lsof, pstat etc.  This places an upper limit on how high
> max_pid can be realistically tuned.

Personally, I don't think this really matters; probably the correct
thing to do if this was an issue would be to cut down the column with
the command name in it.  The thing that really matters is the delimiter
character for "cut -d" for scripts, which should be using that method,
rather than specific column data.  Alternately, for ps, you could set
the "COLUMNS" environment variable to a large number and/or use the "-www"
argument.

FWIW: The hard and fast limit is actually 0x000fffff, from event.h,
because of the way kevents are handled for EVFILT_PROC to stuff the
PID into the hints fiels.  Practically, this works out to 1048575,
before you run out of bits to represent the PID.

Jeffrey Hsu submitted a patch for this once, and I submitted a patch
for this once, which added a separate hint field internally (and added
support for System V IPC kevents).  A side effect of this patch is to
permit contracts betwen user space and the kernel event filters, which
can't be done without the address of a structure, which is one of the
things I was passing around as the (now larger) hint.

In other words, it fixes the Linux complaint about "edge vs. level"
that has kept them from adopting the kqueue/kevent interfaces, by
letting you have a choice in the events, and/or pass around a larger
event buffer for multiple events to be copied out, etc..

-- Terry