From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754053AbbCMVqF (ORCPT ); Fri, 13 Mar 2015 17:46:05 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:58705 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751741AbbCMVqD (ORCPT ); Fri, 13 Mar 2015 17:46:03 -0400 Date: Fri, 13 Mar 2015 14:45:56 -0700 From: josh@joshtriplett.org To: Andy Lutomirski Cc: David Drysdale , Al Viro , Andrew Morton , Ingo Molnar , Kees Cook , Oleg Nesterov , "Paul E. McKenney" , "H. Peter Anvin" , Rik van Riel , Thomas Gleixner , Thiago Macieira , Michael Kerrisk , "linux-kernel@vger.kernel.org" , Linux API , Linux FS Devel , X86 ML Subject: Re: [PATCH 0/6] CLONE_FD: Task exit notification via file descriptor Message-ID: <20150313214556.GB10954@cloud> References: <20150313194252.GA10317@cloud> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 13, 2015 at 02:33:44PM -0700, Andy Lutomirski wrote: > On Fri, Mar 13, 2015 at 12:42 PM, Josh Triplett wrote: > > On Fri, Mar 13, 2015 at 04:05:29PM +0000, David Drysdale wrote: > >> On Fri, Mar 13, 2015 at 1:40 AM, Josh Triplett wrote: > >> > This patch series introduces a new clone flag, CLONE_FD, which lets the caller > >> > handle child process exit notification via a file descriptor rather than > >> > SIGCHLD. CLONE_FD makes it possible for libraries to safely launch and manage > >> > child processes on behalf of their caller, *without* taking over process-wide > >> > SIGCHLD handling (either via signal handler or signalfd). > >> > >> Hi Josh, > >> > >> From the overall description (i.e. I haven't looked at the code yet) > >> this looks very interesting. However, it seems to cover a lot of the > >> same ground as the process descriptor feature that was added to FreeBSD > >> in 9.x/10.x: > >> https://www.freebsd.org/cgi/man.cgi?query=pdfork&sektion=2 > > > > Interesting. > > > >> I think it would ideally be nice for a userspace library developer to be > >> able to do subprocess management (without SIGCHLD) in a similar way > >> across both platforms, without lots of complicated autoconf shenanigans. > >> > >> So could we look at the overlap and seeing if we can come up with > >> something that covers your requirements and also allows for something > >> that looks like FreeBSD's process descriptors? > > > > Agreed; however, I think it's reasonable to provide appropriate Linux > > system calls, and then let glibc or libbsd or similar provide the > > BSD-compatible calls on top of those. I don't think the kernel > > interface needs to exactly match FreeBSD's, as long as it's a superset > > of the functionality. > > We need to be careful with things like read(2), though. It's hard to > write a glibc function that makes read(2) do something other than what > the kernel thinks. Similarly, poll(2) is defined by the kernel. It > would be really nice to be consistent here. It doesn't sound like FreeBSD implements read(2) on the pdfork file descriptor at all. If it does, yes, we're not going to be able to be compatible with that. - Josh Triplett From mboxrd@z Thu Jan 1 00:00:00 1970 From: josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org Subject: Re: [PATCH 0/6] CLONE_FD: Task exit notification via file descriptor Date: Fri, 13 Mar 2015 14:45:56 -0700 Message-ID: <20150313214556.GB10954@cloud> References: <20150313194252.GA10317@cloud> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Drysdale , Al Viro , Andrew Morton , Ingo Molnar , Kees Cook , Oleg Nesterov , "Paul E. McKenney" , "H. Peter Anvin" , Rik van Riel , Thomas Gleixner , Thiago Macieira , Michael Kerrisk , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux API , Linux FS Devel , X86 ML To: Andy Lutomirski Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Mar 13, 2015 at 02:33:44PM -0700, Andy Lutomirski wrote: > On Fri, Mar 13, 2015 at 12:42 PM, Josh Triplett wrote: > > On Fri, Mar 13, 2015 at 04:05:29PM +0000, David Drysdale wrote: > >> On Fri, Mar 13, 2015 at 1:40 AM, Josh Triplett wrote: > >> > This patch series introduces a new clone flag, CLONE_FD, which lets the caller > >> > handle child process exit notification via a file descriptor rather than > >> > SIGCHLD. CLONE_FD makes it possible for libraries to safely launch and manage > >> > child processes on behalf of their caller, *without* taking over process-wide > >> > SIGCHLD handling (either via signal handler or signalfd). > >> > >> Hi Josh, > >> > >> From the overall description (i.e. I haven't looked at the code yet) > >> this looks very interesting. However, it seems to cover a lot of the > >> same ground as the process descriptor feature that was added to FreeBSD > >> in 9.x/10.x: > >> https://www.freebsd.org/cgi/man.cgi?query=pdfork&sektion=2 > > > > Interesting. > > > >> I think it would ideally be nice for a userspace library developer to be > >> able to do subprocess management (without SIGCHLD) in a similar way > >> across both platforms, without lots of complicated autoconf shenanigans. > >> > >> So could we look at the overlap and seeing if we can come up with > >> something that covers your requirements and also allows for something > >> that looks like FreeBSD's process descriptors? > > > > Agreed; however, I think it's reasonable to provide appropriate Linux > > system calls, and then let glibc or libbsd or similar provide the > > BSD-compatible calls on top of those. I don't think the kernel > > interface needs to exactly match FreeBSD's, as long as it's a superset > > of the functionality. > > We need to be careful with things like read(2), though. It's hard to > write a glibc function that makes read(2) do something other than what > the kernel thinks. Similarly, poll(2) is defined by the kernel. It > would be really nice to be consistent here. It doesn't sound like FreeBSD implements read(2) on the pdfork file descriptor at all. If it does, yes, we're not going to be able to be compatible with that. - Josh Triplett