[ dropping virtio-...@lists.oasis-open.org since it is a closed list and
I am tired of deleting bounces ]

On 4/4/18 2:28 AM, Siwei Liu wrote:
> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsah...@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
>> S/W like lldpd should ignore it.
> 
> I'm still not sure I understand your case: why you want to hide the
> control netdev, as I assume those devices could choose either to
> silently ignore the request, or fail loudly against user operations?
> Is it creating issues already, or what problem you want to solve if
> not making the netdev invisible. Why couldn't lldpd check some
> specific flag and ignore the control netdevice (can you please give an
> example of a concrete driver for control netdevice *in tree*).
> 
> And I'm completely lost why you want an API to make a hidden netdev
> visible again for these control devices.

Networking vendors have out of tree kernel modules. Those modules use a
netdev (call it a master netdev, a control netdev, cpu port, whatever)
to pull packets from the ASIC and deliver to virtual netdevices
representing physical ports. The master netdev should not be mucked with
by a user. It should be ignored by certain s/w with lldpd as just an
*example*.

The short of it is that you have your reasons for wanting to hide the
virtio bypass device; other users have other arguments for wanting a
similar capability.

--

>From there I think you are confusing my intentions: I fundamentally do
not believe the kernel should be hiding anything from an admin. Not
showing data by default is completely different than not showing that
data at all.

The intention of my patch with the IFF_HIDDEN attribute is:
1. it is a netdev attribute

2. that attribute can be used by userpsace to indicate to the kernel I
want all or I want the default

3. that attribute can be controlled by an admin.

The patches go beyond my specific use case (preventing a user from
modifying a netdev it should not be touching) but to defining the
semantics of a generic capability which is what the kernel should have.

Reply via email to