From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [RFC PATCH] proc, pidns: Add highpid Date: Fri, 28 Nov 2014 21:34:09 -0600 Message-ID: <87mw7aof2m.fsf@x220.int.ebiederm.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Andy Lutomirski's message of "Fri, 28 Nov 2014 15:05:01 -0800") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: David Herrmann , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton , systemd Mailing List , criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Pavel Emelyanov , Cyrill Gorcunov List-Id: linux-api@vger.kernel.org Andy Lutomirski writes: > Pid reuse is common, which means that it's difficult or impossible > to read information about a pid from /proc without races. Sigh. What we need are not race free pids, but a file descriptor based process management api. Possibly one that starts by handing you a proc directory. Which probably means that we need a proc file we can write to and send signals to a process, and another proc file we can select on and wait for the process to exit. Making pids bigger just looks like bandaid. Remember evovle things in the direction of an object capability system things wind up being more maintainable. Eric