> > Because of such and other reasons it might be a good idea to move to
> > a 32-bit pid in the future, so that pid's will be unique for a process.
>
> glibc already uses 32 bit PIDs. It's again up to the kernel to make
> the move.
>
> In general this brings up the question of whether we want to enforce a
> requirement that people upgrade to glibc when we move forward to the 2.2
> kernel.....
It might not be a terribly good idea to break all of the commercial software
built against libc 5. Linux's reputation for binary compatibility is already
shabby enough.
Could we use a separate personailty for this type of thing? Seems like it
would be easy enough to implement a proper 32bit syscall convention and
provide a kernel-level thunk down to 16bit values where necessary?
Erik
-------------------------------------------------------------------------------
| "Tarball is idiomatically related to furball and hairball" -- Carl D. Roth |
| |
| Erik Troan = ewt@redhat.com = ewt@sunsite.unc.edu |