From: Jiri Pirko <jiri@resnulli.us>
To: David Ahern <dsahern@gmail.com>
Cc: Si-Wei Liu <si-wei.liu@oracle.com>,
mst@redhat.com, stephen@networkplumber.org,
alexander.h.duyck@intel.com, davem@davemloft.net,
jesse.brandeburg@intel.com, kubakici@wp.pl, jasowang@redhat.com,
sridhar.samudrala@intel.com, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Subject: Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
Date: Wed, 4 Apr 2018 08:19:45 +0200 [thread overview]
Message-ID: <20180404061945.GN3313@nanopsycho> (raw)
In-Reply-To: <3bdfc39f-4935-2433-7982-9ce28c3aa166@gmail.com>
Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern@gmail.com wrote:
>On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
>As mentioned in a previous response some kernel drivers create control
>netdevs. Just as in this case users should not be mucking with it, and
virtio_net. Any other drivers?
>S/W like lldpd should ignore it.
It's just a matter of identification of the netdevs, so the user knows
what to do.
>
>>
>>> would prefer a better solution than playing games with name prefixes and
>>> one that includes an API for users to list all devices -- even ones
>>> hidden by default.
>>
>> Netdevice hiding feels a bit scarry for me. This smells like a workaround
>> for userspace issues. Why can't the netdevice be visible always and
>> userspace would know what is it and what should it do with it?
>>
>> Once we start with hiding, there are other things related to that which
>> appear. Like who can see what, levels of visibility etc...
>>
>
>I would not advocate for any API that does not allow users to have full
>introspection. The intent is to hide the netdev by default but have an
>option to see it.
As an administrator, I want to see all by default. I think it is
reasonable requirements. Again, this awfully smells like a workaround...
next prev parent reply other threads:[~2018-04-04 6:19 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-01 9:13 [RFC PATCH 0/3] Userspace compatible driver model for virtio_bypass Si-Wei Liu
2018-04-01 9:13 ` [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device Si-Wei Liu
2018-04-03 12:25 ` Michael S. Tsirkin
2018-04-04 8:02 ` [virtio-dev] " Siwei Liu
2018-04-05 15:31 ` Paolo Bonzini
2018-04-07 2:54 ` Siwei Liu
2018-04-01 9:13 ` [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice Si-Wei Liu
2018-04-01 16:11 ` David Ahern
2018-04-03 7:40 ` Siwei Liu
2018-04-03 14:57 ` David Ahern
2018-04-03 15:42 ` Jiri Pirko
2018-04-03 19:23 ` Siwei Liu
2018-04-04 1:04 ` David Ahern
2018-04-04 6:19 ` Jiri Pirko [this message]
2018-04-04 8:01 ` Siwei Liu
2018-04-04 7:36 ` Siwei Liu
2018-04-04 17:21 ` David Ahern
2018-04-04 17:37 ` David Miller
2018-04-04 18:20 ` Jiri Pirko
2018-04-07 2:32 ` Siwei Liu
2018-04-07 3:19 ` Andrew Lunn
2018-04-09 22:07 ` Siwei Liu
2018-04-09 22:15 ` Andrew Lunn
2018-04-09 22:30 ` Siwei Liu
2018-04-09 23:03 ` Stephen Hemminger
2018-04-09 23:31 ` Siwei Liu
2018-04-08 16:32 ` David Miller
2018-04-10 6:48 ` Siwei Liu
2018-04-18 0:26 ` Siwei Liu
2018-04-18 23:33 ` Samudrala, Sridhar
2018-04-19 4:41 ` Michael S. Tsirkin
2018-04-19 5:00 ` [virtio-dev] " Samudrala, Sridhar
2018-04-19 5:07 ` Michael S. Tsirkin
2018-04-19 6:10 ` [virtio-dev] " Samudrala, Sridhar
2018-04-19 6:43 ` Siwei Liu
2018-04-19 6:31 ` Siwei Liu
2018-04-04 18:02 ` Siwei Liu
2018-04-04 8:28 ` Siwei Liu
2018-04-04 17:37 ` David Ahern
2018-04-04 17:42 ` David Miller
2018-04-04 17:44 ` Stephen Hemminger
2018-04-04 20:08 ` Andrew Lunn
2018-04-03 17:35 ` Stephen Hemminger
[not found] ` <CADGSJ23vZdtQzWdc_6M_Hr4MUej--wgvJ785DwRF3VaPWS1rpA@mail.gmail.com>
[not found] ` <20180403160834.51594373@xeon-e3>
2018-04-06 21:29 ` Siwei Liu
2018-04-01 9:13 ` [RFC PATCH 3/3] virtio_net: make lower netdevs for virtio_bypass hidden Si-Wei Liu
2018-04-03 12:20 ` Michael S. Tsirkin
2018-04-04 8:03 ` [virtio-dev] " Siwei Liu
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=20180404061945.GN3313@nanopsycho \
--to=jiri@resnulli.us \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=kubakici@wp.pl \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=si-wei.liu@oracle.com \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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