Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753979AbXJ0DsS (ORCPT ); Fri, 26 Oct 2007 23:48:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751782AbXJ0DsH (ORCPT ); Fri, 26 Oct 2007 23:48:07 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:34746 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751588AbXJ0DsF (ORCPT ); Fri, 26 Oct 2007 23:48:05 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrew Morton Cc: Adrian Bunk , kir@swsoft.com, containers@lists.osdl.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, kir@openvz.org, Cedric Le Goater , Pavel Emelyanov , Sukadev Bhattiprolu Subject: Re: [Devel] [PATCH] pidns: Place under CONFIG_EXPERIMENTAL (take 2) References: <20071027002448.GH30533@stusta.de> <20071027020408.GO30533@stusta.de> <20071026191845.fd0f75c8.akpm@linux-foundation.org> Date: Fri, 26 Oct 2007 21:46:59 -0600 In-Reply-To: <20071026191845.fd0f75c8.akpm@linux-foundation.org> (Andrew Morton's message of "Fri, 26 Oct 2007 19:18:45 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2951 Lines: 68 Andrew Morton writes: >> On Sat, 27 Oct 2007 04:04:08 +0200 Adrian Bunk wrote: >> > be happy to hear if someone has a better idea. >> >> There is a difference between "complete the feature" and "early adopters >> to start playing with the feature" on the one side, and making something >> available in a released kernel on the other side. >> >> For development and playing with it it can depend on BROKEN (perhaps >> with the dependency removed through the first -rc kernels), but as soon >> as it's available in a -final kernel the ABI is fixed. >> > > Yes, if we're not 100% certain that the interfaces are correnct and unchanging > and that the implementation is solid, we should disable the feature at Kconfig > time. Reasonable. So far things look good for a single pid namespace. Multiple pid namespaces look iffy. > The best option would be to fix things asap. But assuming that option isn't > reasonable and/or safe, we can slip a `depends on BROKEN' into -rc6 then > resume development for 2.6.25. I think we can make a lot of progress but there is enough development yet to do to reach the target of correct and unchanging interfaces, with a solid interface. That unless we achieve a breakthrough I don't see us achieving that target for 2.6.24. The outstanding issues I can think of off the top of my head: - signal handling for init on secondary pid namespaces. - Properly setting si_pid on signals that cross namespaces. - The kthread API conversion so we don't get kernel threads trapped in pid namespaces and make them unfreeable. - At fork time I think we are doing a little bit too much work in setting the session and the pgrp, and removing the controlling tty. - AF_unix domain credential passing. - misc pid vs vpid sorting out (autofs autofs4, coda, arch specific syscalls, others?) - Removal of task->pid, task->tgid, task->signal->__pgrp, tsk->signal->__session or some other way to ensure that we have touched and converted all of the kernel pid handling. - flock pid handling. It hurts me to even ponder what thinking makes it that CONFIG_EXPERIMENTAL isn't enough to keep a stable distro from shipping the code in their stable kernel, and locking us into trouble. With that said. I think I should just respin the patchset now and add the "depends on BROKEN". The user namespace appears to need that treatment as well. The network namespace has so little there and it already depends on !SYSFS so I don't think we are going to run into any trouble with it. Happily I managed to parse that problem differently, so I could slice of the parts of the networking stack that had not been converted. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/