From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754926AbbDICUY (ORCPT ); Wed, 8 Apr 2015 22:20:24 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:33477 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754357AbbDICUA (ORCPT ); Wed, 8 Apr 2015 22:20:00 -0400 X-Originating-IP: 67.139.65.163 Date: Wed, 8 Apr 2015 19:19:49 -0700 From: Josh Triplett To: Jonathan Corbet Cc: Al Viro , Andrew Morton , Andy Lutomirski , Ingo Molnar , Kees Cook , Oleg Nesterov , "Paul E. McKenney" , "H. Peter Anvin" , Rik van Riel , Thomas Gleixner , Michael Kerrisk , Thiago Macieira , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor Message-ID: <20150409021948.GA1027@jtriplet-mobl1> References: <20150331220807.6927e780@lwn.net> <20150331220224.GA22707@cloud> <20150401092420.4c1dbb6e@lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401092420.4c1dbb6e@lwn.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 01, 2015 at 09:24:20AM +0200, Jonathan Corbet wrote: > On Tue, 31 Mar 2015 15:02:24 -0700 > josh@joshtriplett.org wrote: > > > > This would appear to assume that a clonefd_info structure is the only > > > thing that will ever be read from this descriptor. It seems to me that > > > there is the potential for, someday, wanting to be able to read and write > > > other things as well. Should this structure be marked with type and > > > length fields so that other structures could be added in the future? > > > > I don't think it makes sense for a caller to get an arbitrary structure > > on read(), and have to figure out what they got and ignore something > > they don't understand. Instead, I think it makes more sense for the > > caller to say "Hey, here's a flag saying I understand the new thing, go > > ahead and give me the new thing". So, for instance, if you want to > > receive SIGSTOP/SIGCONT messages for child processes through this > > descriptor, we could add a flag for that. > > The flag is fine, but, once we have set that flag saying we want those > messages, how do we know which type of structure we've gotten? That's > the piece of the puzzle I'm missing, sorry if I'm being overly slow. If you pass a flag saying you can handle a new set of potential structures, those structures can then include any necessary disambiguating flags/IDs/etc. No need for them to match the current clonefd_info structure if userspace has opted into a new version. - Josh Triplett