From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [RFC][PATCH 0/4] Object creation with a specified id Date: Fri, 14 Mar 2008 19:08:38 +0300 Message-ID: <47DAA306.1080109@openvz.org> References: <20080310135054.312992000@bull.net> <47D9B5B7.6060803@cs.columbia.edu> <47DA195B.8070704@bull.net> <47DA9EB5.8040704@cs.columbia.edu> <47DAA041.9090009@openvz.org> <47DAA1A6.6010509@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47DAA1A6.6010509-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oren Laadan Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: containers.vger.kernel.org Oren Laadan wrote: > > Pavel Emelyanov wrote: >> Oren Laadan wrote: >>> Nadia Derbey wrote: >>>> Oren Laadan wrote: >>>>> Nadia.Derbey-6ktuUTfB/bM@public.gmane.org wrote: >>>>> >>>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>>> proposal for >>>>>> a new syscall to change an ipc id (see thread >>>>>> http://lkml.org/lkml/2008/1/29/209). >>>>>> >>>>>> >>>>>> Oren's suggestion was to force an object's id during its creation, >>>>>> rather >>>>>> than 1. create it, 2. change its id. >>>>>> >>>>>> So here is an implementation of what Oren has suggested. >>>>>> >>>>>> 2 new files are defined under /proc/self: >>>>>> . next_ipcid --> next id to use for ipc object creation >>>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>>> (see patch #2 for more details). >>>>> Generally looks good. One meta-comment, though: >>>>> >>>>> I wonder why you use separate files for separate resources, >>>> That would be needed in a situation wheere we don't care about next, >>>> say, ipc id to be created but we need a predefined pid. But I must admit >>>> I don't see any pratical application to it. >>> exactly; why set the next-ipc value so far in advance ? I think it's >>> better (and less confusing) if we require that setting the next-id value >>> be done right before the respective syscall. >> And race with some other syscall caller? This will only work if the next-ipc-id >> and the next-pid are on a task_struct. Are they (at least supposed to be such)? > > yes. that's the first detail I looked for in the patch :) OK :) I just remembered some talks about using last_pid for pid allocations and just wanted to be sure.