From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E8F2C433F5 for ; Thu, 18 Nov 2021 19:22:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7AE71610F8 for ; Thu, 18 Nov 2021 19:22:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233734AbhKRTZa (ORCPT ); Thu, 18 Nov 2021 14:25:30 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:35404 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231825AbhKRTZ1 (ORCPT ); Thu, 18 Nov 2021 14:25:27 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]:57172) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mnmzJ-000lSE-22; Thu, 18 Nov 2021 12:22:25 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:48176 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mnmzH-003iYF-Is; Thu, 18 Nov 2021 12:22:24 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Steven Rostedt Cc: "Yordan Karadzhov \(VMware\)" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, mingo@redhat.com, hagen@jauu.net, rppt@kernel.org, James.Bottomley@HansenPartnership.com, akpm@linux-foundation.org, vvs@virtuozzo.com, shakeelb@google.com, christian.brauner@ubuntu.com, mkoutny@suse.com, Linux Containers References: <20211118181210.281359-1-y.karadz@gmail.com> <87a6i1xpis.fsf@email.froward.int.ebiederm.org> <20211118140211.7d7673fb@gandalf.local.home> Date: Thu, 18 Nov 2021 13:22:16 -0600 In-Reply-To: <20211118140211.7d7673fb@gandalf.local.home> (Steven Rostedt's message of "Thu, 18 Nov 2021 14:02:11 -0500") Message-ID: <87pmqxuv4n.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mnmzH-003iYF-Is;;;mid=<87pmqxuv4n.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18gQzuWpaBgAEXLLCGhz+F3zKEDvRmChIA= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt writes: > On Thu, 18 Nov 2021 12:55:07 -0600 > ebiederm@xmission.com (Eric W. Biederman) wrote: > >> Nacked-by: "Eric W. Biederman" >> >> Eric > > Eric, > > As you can see, the subject says "Proof-of-Concept" and every patch in the > the series says "RFC". All you did was point out problems with no help in > fixing those problems, and then gave a nasty Nacked-by before it even got > into a conversation. > > From this response, I have to say: > > It is not correct to nack a proof of concept that is asking for > discussion. > > So, I nack your nack, because it's way to early to nack this. I am refreshing my nack on the concept. My nack has been in place for good technical reasons since about 2006. I see no way forward. I do not see a compelling use case. There have been many conversations in the past attempt to implement something that requires a namespace of namespaces and they have never gotten anywhere. I see no attempt a due diligence or of actually understanding what hierarchy already exists in namespaces. I don't mean to be nasty but I do mean to be clear. Without a compelling new idea in this space I see no hope of an implementation. What they are attempting to do makes it impossible to migrate a set of process that uses this feature from one machine to another. AKA this would be a breaking change and a regression if merged. The breaking and regression are caused by assigning names to namespaces without putting those names into a namespace of their own. That appears fundamental to the concept not to the implementation. Since the concept if merged would cause a regression it qualifies for a nack. We can explore what problems they are trying to solve with this and explore other ways to solve those problems. All I saw was a comment about monitoring tools and wanting a global view. I did not see any comments about dealing with all of the reasons why a global view tends to be a bad idea. I should have added that we have to some extent a way to walk through namespaces using ioctls on nsfs inodes. Eric