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]
Date:   Tue, 19 Jul 2022 03:03:26 +0200
From:   Max Staudt <max@...as.org>
To:     Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>,
        Dario Binacchi <dario.binacchi@...rulasolutions.com>,
        linux-kernel@...r.kernel.org,
        Jeroen Hofstee <jhofstee@...tronenergy.com>,
        michael@...rulasolutions.com,
        Amarula patchwork <linux-amarula@...rulasolutions.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 2/5] can: slcan: remove legacy infrastructure

On Mon, 18 Jul 2022 12:23:05 +0200
Oliver Hartkopp <socketcan@...tkopp.net> wrote:

> IMO it does not break user space when slcan gets the common naming 
> schema for CAN interface names.

For what it's worth, slcan provides a specific ioctl to resolve from
(tty fd) to (netdev name). As far as I can see, any sane program should
use this API to find whatever device it has created, irrespective of
the netdev name.


@ Marc: slcand and slcan_attach in can-utils do not depend on the
slcanX name, as far as I can see. They are the main interfaces to
slcan, and apart from that I can only think of scripts doing netlink
stuff and scanning for slcanX. Does this change your opinion, or is
breaking such scripts already a step too far?

I'm thinking that in other circumstances, I've had cases where devices
were numbered differently just because they enumerated faster or slower
at different boots, or with other kernel versions, or because of media
inserted, etc. - though renumbering is of course one step less than
changing the prefix.


> We had the same thing with 'eth0' which is now named enblablabla or 
> 'wlan0' now named wlp2s0.

Actually, the kernel still calls them ethX and wlanX. It's systemd+udev
that renames them to the "unique" names afterwards. It's an extra step
that happens in userspace.

udev is immensely useful, but also great stuff for race conditions :)



Max

Powered by blists - more mailing lists