On 4/3/18 1:40 AM, Siwei Liu wrote: >> There are other use cases that want to hide a device from userspace. > > Can you elaborate your case in more details? Looking at the links > below I realize that the purpose of hiding devices in your case is > quite different from the our migration case. Particularly, I don't
some kernel drivers create "control" netdev's. They are not intended for users to manipulate and doing so may actually break networking. > like the part of elaborately allowing user to manipulate the link's > visibility - things fall apart easily while live migration is on > going. And, why doing additional check for invisible links in every > for_each_netdev() and its friends. This is effectively changing > semantics of internal APIs that exist for decades. Read the patch again: there are 40 references to for_each_netdev and that patch touches 2 of them -- link dumps via rtnetlink and link dumps via ioctl. >> one that includes an API for users to list all devices -- even ones > > What kind of API you would like to query for hidden devices? > rtnetlink? a private socket API? or something else? There are existing, established APIs for dumping links. No new API is needed. As suggested in the 2 patches I referenced the hidden / invisibility cloak is an attribute of the device. When a link dump is requested if the attribute is set, the device is skipped and not included in the dump. However, if the user knows the device name the GETLINK / SETLINK / DELLINK apis all work as normal. This allows the device to be hidden from apps like snmpd, lldpd, etc, yet still usable. > > For our case, the sysfs interface is what we need and is sufficient, > since udev is the main target we'd like to support to make the naming > of virtio_bypass consistent and compatible. You are not hiding a device if it is visible in 1 API (/sysfs) and not visible by another API (rtnetlink). That only creates confusion. > >> hidden by default. >> >> https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00 >> >> https://github.com/dsahern/iproute2/commit/7563f5b26f5539960e99066e34a995d22ea908ed >> >> Also, why are you suggesting that the device should still be visible via >> /sysfs? That leads to inconsistent views of networking state - /sys >> shows a device but a link dump does not. > > See my clarifications above. I don't mind kernel-only netdevs being > visible via sysfs, as that way we get a good trade-off between > backwards compatibility and visibility. There's still kobject created > there right. Bottom line is that all kernel devices and its life-cycle > uevents are made invisible to userpace network utilities, and I think > it simply gets to the goal of not breaking existing apps while being > able to add new features.
