public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Enrico Weigelt\, metux IT consult" <lkml@metux.net>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	Hannes Reinecke <hare@suse.de>,
	gregkh@linuxfoundation.org, containers@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: device namespaces
Date: Mon, 14 Jun 2021 12:36:19 -0500	[thread overview]
Message-ID: <874ke0s60c.fsf@disp2133> (raw)
In-Reply-To: <c504a8c6-73f8-b45c-6d6b-6f5a1300ab3a@metux.net> (Enrico Weigelt's message of "Mon, 14 Jun 2021 09:49:22 +0200")

"Enrico Weigelt, metux IT consult" <lkml@metux.net> 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

  parent reply	other threads:[~2021-06-14 17:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  9:38 device namespaces Enrico Weigelt, metux IT consult
2021-06-08 12:30 ` Christian Brauner
2021-06-08 12:41   ` Greg Kroah-Hartman
2021-06-08 14:10     ` Hannes Reinecke
2021-06-08 14:29       ` Christian Brauner
2021-06-08 15:54         ` Hannes Reinecke
2021-06-08 17:16           ` Eric W. Biederman
2021-06-09  6:38             ` Christian Brauner
2021-06-09  7:02               ` Hannes Reinecke
2021-06-09  7:21                 ` Christian Brauner
2021-06-09  7:54                   ` Hannes Reinecke
2021-06-09  8:09                     ` Christian Brauner
2021-06-11 18:14                       ` Eric W. Biederman
2021-06-14  7:49                         ` Enrico Weigelt, metux IT consult
2021-06-14  8:22                           ` Greg KH
2021-06-14 17:36                           ` Eric W. Biederman [this message]
2021-06-15 11:24                             ` Enrico Weigelt, metux IT consult
2021-06-15 11:33                               ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874ke0s60c.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox