search for: iff_hidden

...tion purpose, the >> kobject for hidden netdev still presents in the sysfs >> hierarchy, however, no uevent message will be generated >> when the sysfs entry is created, modified or destroyed. >> >> For that end, a separate namescope needs to be carved >> out for IFF_HIDDEN netdevs. As of now netdev name that >> starts with colon i.e. ':' is invalid in userspace, >> since socket ioctls such as SIOCGIFCONF use ':' as the >> separator for ifname. The absence of namescope started >> with ':' can rightly be used as the names...

...netdev. For identification purpose, the > kobject for hidden netdev still presents in the sysfs > hierarchy, however, no uevent message will be generated > when the sysfs entry is created, modified or destroyed. > > For that end, a separate namescope needs to be carved > out for IFF_HIDDEN netdevs. As of now netdev name that > starts with colon i.e. ':' is invalid in userspace, > since socket ioctls such as SIOCGIFCONF use ':' as the > separator for ifname. The absence of namescope started > with ':' can rightly be used as the namescope for > th...

...ion purpose, the >> kobject for hidden netdev still presents in the sysfs >> hierarchy, however, no uevent message will be generated >> when the sysfs entry is created, modified or destroyed. >> >> For that end, a separate namescope needs to be carved >> out for IFF_HIDDEN netdevs. As of now netdev name that >> starts with colon i.e. ':' is invalid in userspace, >> since socket ioctls such as SIOCGIFCONF use ':' as the >> separator for ifname. The absence of namescope started >> with ':' can rightly be used as the names...

...netdev still presents in the sysfs >> >> hierarchy, however, no uevent message will be generated >> >> when the sysfs entry is created, modified or destroyed. >> >> >> >> For that end, a separate namescope needs to be carved >> >> out for IFF_HIDDEN netdevs. As of now netdev name that >> >> starts with colon i.e. ':' is invalid in userspace, >> >> since socket ioctls such as SIOCGIFCONF use ':' as the >> >> separator for ifname. The absence of namescope started >> >> with ':...

...erly know what to do with and how to handle these devices. If you hide these objects, we are basically giving up on fixing the tools and or the drivers themselves to be architected differently (see #2 above). That really isn't acceptable in my opinion. > 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 f...

Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern at 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

On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern at 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

On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern at 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

On Wed, 4 Apr 2018 11:37:52 -0600 David Ahern <dsahern at gmail.com> wrote: > 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.

On Wed, Apr 4, 2018 at 10:21 AM, David Ahern <dsahern at gmail.com> wrote: > On 4/4/18 1:36 AM, Siwei Liu wrote: >> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern at 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 >>>>

> 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. Sounds a lot like DSA. Please ask the vendor to contribute the drivers :-) > The master netdev should not be mucked with by a user. It

On Fri, Apr 6, 2018 at 8:19 PM, Andrew Lunn <andrew at lunn.ch> wrote: > Hi Siwei > >> I think everyone seems to agree not to fiddle with the ":" prefix, but >> rather have a new class of network subsystem under /sys/class thus a >> separate device namespace e.g. /sys/class/net-kernel for those >> auto-managed lower netdevs is needed. > > How do

On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn <andrew at lunn.ch> wrote: >> No, implementation wise I'd avoid changing the class on the fly. What >> I'm looking to is a means to add a secondary class or class aliasing >> mechanism for netdevs that allows mapping for a kernel device >> namespace (/class/net-kernel) to userspace (/class/net). Imagine >>

On Wed, Apr 4, 2018 at 10:37 AM, David Miller <davem at davemloft.net> wrote: > From: David Ahern <dsahern at gmail.com> > Date: Wed, 4 Apr 2018 11:21:54 -0600 > >> It is a netdev so there is no reason to have a separate ip command to >> inspect it. 'ip link' is the right place. > > I agree on this. I'm completely fine of having an API for

On Sun, Apr 8, 2018 at 9:32 AM, David Miller <davem at davemloft.net> wrote: > From: Siwei Liu <loseweigh at gmail.com> > Date: Fri, 6 Apr 2018 19:32:05 -0700 > >> And I assume everyone here understands the use case for live >> migration (in the context of providing cloud service) is very >> different, and we have to hide the netdevs. If not, I'm more

On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote: > On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote: >> On 4/17/2018 5:26 PM, Siwei Liu wrote: >>> I ran this with a few folks offline and gathered some good feedbacks >>> that I'd like to share thus revive the discussion. >>> >>> First of all, as illustrated in the reply below, cloud

Hi Siwei > I think everyone seems to agree not to fiddle with the ":" prefix, but > rather have a new class of network subsystem under /sys/class thus a > separate device namespace e.g. /sys/class/net-kernel for those > auto-managed lower netdevs is needed. How do you get a device into this new class? I don't know the Linux driver model too well, but to get a device

Hi Siwei > I think everyone seems to agree not to fiddle with the ":" prefix, but > rather have a new class of network subsystem under /sys/class thus a > separate device namespace e.g. /sys/class/net-kernel for those > auto-managed lower netdevs is needed. How do you get a device into this new class? I don't know the Linux driver model too well, but to get a device

On 4/18/2018 10:07 PM, Michael S. Tsirkin wrote: > On Wed, Apr 18, 2018 at 10:00:51PM -0700, Samudrala, Sridhar wrote: >> On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote: >>> On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote: >>>> On 4/17/2018 5:26 PM, Siwei Liu wrote: >>>>> I ran this with a few folks offline and gathered some good

> No, implementation wise I'd avoid changing the class on the fly. What > I'm looking to is a means to add a secondary class or class aliasing > mechanism for netdevs that allows mapping for a kernel device > namespace (/class/net-kernel) to userspace (/class/net). Imagine > creating symlinks between these two namespaces as an analogy. All > userspace visible netdevs