linux-kernel - Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHNKnsTY0cV4=V7t0Q3p4-hO5t9MbWWM-X0MJFRKCZ1SG0ucUg@mail.gmail.com>
Date:   Thu, 3 Feb 2022 05:20:34 +0300
From:   Sergey Ryazanov <ryazanov.s.a@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Oliver Neukum <oneukum@...e.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, kernel@...gutronix.de,
        open list <linux-kernel@...r.kernel.org>,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree

Hello Greg,

if I may be allowed, I would like to make a couple of points about
specifying network interface names in DT. As in previous mail, not to
defend this particular patch, but to talk about names assignment in
general.

I may be totally wrong, so consider my words as a request for
discussion. I have been thinking about an efficient way for network
device names assignment for routers with a fixed configuration and
have always come to a conclusion that DT is a good place for names
storage. Recent DSA capability to assign names from labels and this
patch by Oleksij show that I am not alone.

On Fri, Jan 28, 2022 at 3:34 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> And again, pick your names in userspace, embedded is not "special" here.

Embedded is not a special case, but fixed configuration is.

> You can do persistant network device names in a very trivial shell
> script if needed, we used to do it that way 18 years ago :)

Network device name is not a solely userspace entity. It is part of
the interface between the kernel and userspace software.

Sure, persistent names can be established with a userspace script. But
this implies the device renaming, which is a complex and race prone
task. Once I even found a comment in the kernel code that only network
devices could be renamed and this is a headache. As for userspace, it
is possible to workaround the device renaming issues. But this
requires a lot of code in many programs and sometimes even special
conventions on a programs interaction. E.g. consider a case where a
service would like to bind to a network interface, which is in the
middle of renaming by udev. On the other hand, we have the kernel that
could provide predictable names from the beginning for all software on
a host. So this is a desired option.

As for DT, this is an excellent database with perfectly established
relations to hardware configuration. And if we try to implement a
userspace storage with the network device names, then we will just
duplicate the DT in the userspace, as already was mentioned by
Oleksij. To me, implementation of a names database in userspace looks
more like reinventing the  DT (wheel) than adding device names to the
DT.

To summarize, we (developers of embedded software) have two related needs:
1) the need for persistent names provided by the kernel,
2) using the DT as a source of persistent names for (1).

Greg, what do you think about device names storing in DeviceTree in
the above context? Does it still make no sense?

-- 
Sergey