netdev - Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames

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: <CAJieiUi3n2kKGBVogHBJOd1q+fUjm8ik+xKvDTOxodnZjmH2WQ@mail.gmail.com>
Date:   Sat, 10 Aug 2019 12:39:31 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        David Ahern <dsahern@...il.com>, dcbw@...hat.com,
        Andrew Lunn <andrew@...n.ch>, parav@...lanox.com,
        Saeed Mahameed <saeedm@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and
 delete alternative ifnames

On Sat, Aug 10, 2019 at 8:50 AM Michal Kubecek <mkubecek@...e.cz> wrote:
>
> On Sat, Aug 10, 2019 at 06:46:57AM -0700, Roopa Prabhu wrote:
> > On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek <mkubecek@...e.cz> wrote:
> > >
> > > On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > > > to that point, I am also not sure why we have a new API For multiple
> > > > names. I mean why support more than two names  (existing old name and
> > > > a new name to remove the length limitation) ?
> > >
> > > One use case is to allow "predictable names" from udev/systemd to work
> > > the way do for e.g. block devices, see
> > >
> > >   http://lkml.kernel.org/r/20190628162716.GF29149@unicorn.suse.cz
> > >
> >
> > thanks for the link. don't know the details about alternate block
> > device names. Does user-space generate multiple and assign them to a
> > kernel object as proposed in this series ?. is there a limit to number
> > of names ?. my understanding of 'predictable names' was still a single
> > name but predictable structure to the name.
>
> It is a single name but IMHO mostly because we can only have one name.
> For block devices, udev uses symlinks to create multiple aliases based
> on different naming schemes, e.g.
>
> mike@...n:~> find -L /dev/disk/ -samefile /dev/sda2 -exec ls -l {} +
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WMC1T3114933-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/scsi-0ATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/scsi-1ATA_WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/scsi-350014ee6589cfea0-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-id/wwn-0x50014ee6589cfea0-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-partlabel/root2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-partuuid/71affb47-a93b-40fd-8986-d2e227e1b39d -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-path/pci-0000:00:11.0-ata-1-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 srp  5 21:47 /dev/disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0-part2 -> ../../sda2
>
> Few years ago, udev even dropped support for renaming block and
> character devices (NAME="...") so that it now keeps kernel name and only
> creates symlinks to it. Recent versions only allow NAME="..." for
> network devices.


ok thanks for the details. This looks like names that are structured
on hardware info which could fall into devlinks scope and they point
to a single name.
We should think about keeping them under devlink (by-id, by-mac etc).
It already can recognize network interfaces by id.

The netdev IFLA_NAME falls more under user-defined name with no
structure (dummy1, dummy1-longname) which network interface managers,
protocols etc use.
 Since the goal of the series is to relax the IFLA_NAME limit, I was
hoping it can be replaced by a single attribute that apps can use in
lieu of IFLA_NAME when available.

I would vote for keeping  the structured and user defined unstructured
names separate and that would help with simplifying the API in this
series.