From: Greg KH <gregkh@linuxfoundation.org>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Hannes Reinecke <hare@suse.de>,
containers@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: device namespaces
Date: Mon, 14 Jun 2021 10:22:51 +0200 [thread overview]
Message-ID: <YMcR2982KSjFu8kM@kroah.com> (raw)
In-Reply-To: <c504a8c6-73f8-b45c-6d6b-6f5a1300ab3a@metux.net>
On Mon, Jun 14, 2021 at 09:49:22AM +0200, Enrico Weigelt, metux IT consult wrote:
> 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 ?
>
> I'm yet unsure what the better way is. If we're just talking about pty's
> specifically, I maybe could live with threating them like "special sort
> of pipes", but I guess that would require some extra magic.
>
> If I'm not mistaken, the whole sysfs stuff is automatically handled
> device classes and bus'es - seems that tty's are also class devs.
>
> 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) ?
Wait, step back. What _EXACTLY_ are you wanting to do here? If you
have not looked at how sysfs handles devices today, that leads me to
believe that you do not have a real model in place.
Again, spend some time and write some code please before continuing this
thread. We don't like to talk about vague things when you do not even
have an idea of what you want.
good luck!
greg k-h
next prev parent reply other threads:[~2021-06-14 8:23 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 [this message]
2021-06-14 17:36 ` Eric W. Biederman
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=YMcR2982KSjFu8kM@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux.dev \
--cc=ebiederm@xmission.com \
--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