Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2943452pxj; Mon, 14 Jun 2021 10:38:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzW9HacTKdGuQlFkGa/UsusJiB5ovDA3hWcFzDzyjI4JL1wpZVkjLfqF+XJS76nzJNenPvg X-Received: by 2002:aa7:d304:: with SMTP id p4mr18278107edq.29.1623692292038; Mon, 14 Jun 2021 10:38:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623692292; cv=none; d=google.com; s=arc-20160816; b=aqpi27ZIvXnKUT54V77a07fWKFiFj3p4/S5OnvbyGyycJbImZsaCIyBsGCZz7LI5tz or6lAIS1wTswQceMq+iCMGFGtUDn/uvxpLpcElpfEzwkDCn89iPwsqFMcp3Lm292Fz8m RK+WkevOOb5DJ5tzjAD0/lH69KRKmqIwFr66xLMaC+41nIu8NEsrFeTH8caZPo1IJNcv IlOUqy2lv/jx2X7E+4/rOmQ+w1duiiRNfSqut9GBU30wwMgSeGSGRh7nF3fOKu4ykjnG E9S0R5zUPWryoJ+c7nEg3NSXdAsLARTQJ1JyErp7iDbri9UkYTu6xyr0AIr8rY52FLCc VCXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=aTFhHyULMRWJ9aLNMRgcayECtQqY05R1WQKyFu7RfJM=; b=GDQ2X92tE2LHJ7KL+yOQHl5OmyrLctx4+tJ45mfOGF2b5WoIih4cpwwCr6S0fCIQW6 Mtx+RHCN2WebkrjGItiv10mnfF25p80mEvwO/ZGuwK4oZQhM7+y9qKP6CvKBlCpK40tz IPa4jzOmL0xpfguOtHuqIvPO1acc3J0G/9Uf9KfWHlFj84qhZaM6YJp95kQLBjCeKuXU WJYALv+FhwoaBbAsFsslVcXdi9XADKMfLN4LPeAA4+WmN+5gUVpDALdEZT5ZXTnNhF7a y5npf4L5ZDl9FtP1ignzpbF+jJEUxJ0UH1U85gPTYDKpqx3mIjPoEf5q/NpnIMTH5jZ/ Qexw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b10si8049001ede.515.2021.06.14.10.37.49; Mon, 14 Jun 2021 10:38:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234862AbhFNRie (ORCPT + 99 others); Mon, 14 Jun 2021 13:38:34 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:43174 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233510AbhFNRic (ORCPT ); Mon, 14 Jun 2021 13:38:32 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lsqVg-00EAHg-Rf; Mon, 14 Jun 2021 11:36:28 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.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 1lsqVf-00AJ9J-8D; Mon, 14 Jun 2021 11:36:28 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: "Enrico Weigelt\, metux IT consult" Cc: Christian Brauner , Hannes Reinecke , gregkh@linuxfoundation.org, containers@lists.linux.dev, linux-kernel@vger.kernel.org References: <9157affa-b27a-c0f4-f6ee-def4a991fd4e@suse.de> <20210608142911.ievp2rpuquxjuyus@wittgenstein> <877dj4ff9g.fsf@disp2133> <20210609063818.xnod4rzvti3ujkvn@wittgenstein> <20210609072108.ldhsxfnfql4pacqx@wittgenstein> <85a0d777-dea6-9574-8946-9fc8f912c1af@suse.de> <20210609080918.ma2klvxkjad4pjrn@wittgenstein> <87v96k1d65.fsf@disp2133> Date: Mon, 14 Jun 2021 12:36:19 -0500 In-Reply-To: (Enrico Weigelt's message of "Mon, 14 Jun 2021 09:49:22 +0200") Message-ID: <874ke0s60c.fsf@disp2133> 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=1lsqVf-00AJ9J-8D;;;mid=<874ke0s60c.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18oIIyhANhT0NvXzEtqGitDOHZZn1qI5O4= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa06.xmission.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4981] * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Enrico Weigelt\, metux IT consult" X-Spam-Relay-Country: X-Spam-Timing: total 823 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 11 (1.3%), b_tie_ro: 9 (1.1%), parse: 1.11 (0.1%), extract_message_metadata: 13 (1.5%), get_uri_detail_list: 1.67 (0.2%), tests_pri_-1000: 6 (0.7%), tests_pri_-950: 1.33 (0.2%), tests_pri_-900: 1.13 (0.1%), tests_pri_-90: 137 (16.7%), check_bayes: 126 (15.3%), b_tokenize: 7 (0.8%), b_tok_get_all: 6 (0.8%), b_comp_prob: 2.4 (0.3%), b_tok_touch_all: 107 (13.0%), b_finish: 0.89 (0.1%), tests_pri_0: 637 (77.4%), check_dkim_signature: 0.96 (0.1%), check_dkim_adsp: 3.0 (0.4%), poll_dns_idle: 0.46 (0.1%), tests_pri_10: 2.1 (0.3%), tests_pri_500: 10 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: device namespaces 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 "Enrico Weigelt, metux IT consult" writes: > On 11.06.21 20:14, Eric W. Biederman wrote: > > Hi, > >> I favor none of the virtual devices showing up in sysfs. Maybe existing >> userspace needs the devices in sysfs, but if the solution is simply to >> skip sysfs for virtual devices that is much simpler. > > Sorry for being a little bit confused, but by virtual devices you mean > things like pty's or all the other stuff we already see under > /sys/device/virtual ? By virtual devices I mean all devices that are not physical pieces of hardware. For block devices I mean devices such as loopback devices that are created on demand. Ramdisks that start this conversation could also be considered virtual devices. > How would you skip the virtual devices from sysfs ? Adding some filter > into sysfs that looks at the device class (or some flag within it) ? I would just not run the code to create sysfs entries when the virtual devices are created. If you have virtual devices showing up in their own filesystem they don't even need major or minor numbers. You can just have files that accept ioctls like device nodes. In principle it is possible to skip a lot of the historical infrastructure. If the infrastructure is not needed it is worth skipping. I haven't dug into the block layer recently enough to say what is needed or not. I think there are some thing such as stat on a mounted filesystem that need a major and minor numbers. Which probably means you have to use major and minor numbers. By virtue of using common infrastructure that implies showing up in sysfs and devtmpfs. Things would be limited just by not mounting devtmpfs in a container. It is worth checking how much of the common infrastructure you need when you start creating virtual devices. The only reason the network devices need changes to sysfs is to allow different network devices with the same name to show up in different network namespaces. If you can fundamentally avoid the problem of devices with the same name needing to show up in sysfs and devtmpfs by using filesystems then sysfs and devtmpfs needs no changes. Hotplug is sufficiently widespread now that it should be possible to avoid the hard problem of having duplicate names for block devices, one way or another. Thus talking of changing sysfs seems completely unnecessary. Eric