On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote:
> looking at my process list after a week or so of uptime I discoverd that PIDs
> seem to wrap around at 32767 (aka. 2^15 - 1).
> I find this "feature" annoying, since I like to view my process list sorted
> by PID, which gives a nice overview about recently started processes vs.
> age-old daemons.
> So, I would like to ask if someone could please explain the reason for this.
> If there is no compelling reason I would like to propose to remove this
> limit. I recall this was not present in 2.2.x
You recall incorrectly.
The code is old.
There is very little reason for it, and we could change today.
In fact I think I once submitted the corresponding patch.
My machines regularly see 6- or 7-digit PIDs.
There are two very minor points:
(i) If you are in the habit of tar'ing up /proc, and moreover the
tar you use considers files with the same device and inode to be
identical, then your tarfiles may become smaller after the patch
-#define fake_ino(pid,ino) (((pid)<<16)|(ino))
+#define fake_ino(pid,ino) (((1)<<16)|(ino))
(ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
is used for the fields msg_lspid and msg_lrpid of the (obsolete)
struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
struct shmid_ds. Nothing compiled today uses this, and almost nothing
uses it at all, but this nevertheless means that one needs an option
CONFIG_15BIT_PID (default=N) for backward binary compatibility.
[The patch is available. There are a few security advantages.
Also, it makes a fork a just measurable fraction of a percent faster.]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:23 EST