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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E33BC2BBFD for ; Mon, 13 Apr 2020 19:59:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EE37D20656 for ; Mon, 13 Apr 2020 19:59:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388178AbgDMT7V (ORCPT ); Mon, 13 Apr 2020 15:59:21 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:45697 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388135AbgDMT7U (ORCPT ); Mon, 13 Apr 2020 15:59:20 -0400 Received: from ip5f5bd698.dynamic.kabel-deutschland.de ([95.91.214.152] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jO5Ej-0003pF-4y; Mon, 13 Apr 2020 19:59:17 +0000 Date: Mon, 13 Apr 2020 21:59:15 +0200 From: Christian Brauner To: Tejun Heo Cc: Jens Axboe , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-api@vger.kernel.org, Jonathan Corbet , Serge Hallyn , "Rafael J. Wysocki" , "David S. Miller" , Saravana Kannan , Jan Kara , David Howells , Seth Forshee , David Rheinsberg , Tom Gundersen , Christian Kellner , Dmitry Vyukov , =?utf-8?B?U3TDqXBoYW5l?= Graber , linux-doc@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 5/8] kernfs: let objects opt-in to propagating from the initial namespace Message-ID: <20200413195915.yo2l657nmtkwripb@wittgenstein> References: <20200408152151.5780-1-christian.brauner@ubuntu.com> <20200408152151.5780-6-christian.brauner@ubuntu.com> <20200413190239.GG60335@mtj.duckdns.org> <20200413193950.tokh5m7wsyrous3c@wittgenstein> <20200413194550.GJ60335@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200413194550.GJ60335@mtj.duckdns.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 13, 2020 at 03:45:50PM -0400, Tejun Heo wrote: > Hello, > > On Mon, Apr 13, 2020 at 09:39:50PM +0200, Christian Brauner wrote: > > Another problem is that you might have two devices of the same class > > with the same name that belong to different namespaces and if you shown > > them all in the initial namespace you get clashes. This was one of the > > original reasons why network devices are only shown in the namespace > > they belong to but not in any other. > > For example, pid namespace has the same issue but it doesn't solve the problem > by breaking up visibility at the root level - it makes everything visiable at > root but give per-ns aliases which are selectively visble depending on the > namespace. From administration POV, this is way easier and less error-prone to > deal with and I was hoping that we could head that way rather than netdev way > for new things. Right, pid namespaces deal with a single random identifier about which userspace makes no assumptions other than that it's a positive number so generating aliases is fine. In addition pid namespaces are nicely hierarchical. I fear that we might introduce unneeded complexity if we go this way and start generating aliases for devices that userspace already knows about and has expectations of. We also still face some of the other problems I mentioned. I do think that what you say might make sense to explore in more detail for a new device class (or type under a given class) that userspace does not yet know about and were we don't regress anything.