From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice Date: Tue, 3 Apr 2018 08:57:58 -0600 Message-ID: References: <1522573990-5242-1-git-send-email-si-wei.liu@oracle.com> <1522573990-5242-3-git-send-email-si-wei.liu@oracle.com> <8b589cd2-1abc-59c2-99f1-96df8174bb6b@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Si-Wei Liu , "Michael S. Tsirkin" , Jiri Pirko , Stephen Hemminger , Alexander Duyck , David Miller , "Brandeburg, Jesse" , Jakub Kicinski , Jason Wang , "Samudrala, Sridhar" , Netdev , virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org To: Siwei Liu Return-path: Received: from mail-pl0-f68.google.com ([209.85.160.68]:35623 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751754AbeDCO6C (ORCPT ); Tue, 3 Apr 2018 10:58:02 -0400 Received: by mail-pl0-f68.google.com with SMTP id 61-v6so7181442plb.2 for ; Tue, 03 Apr 2018 07:58:02 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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.