On Sat, Aug 10, 2019 at 8:50 AM Michal Kubecek <mkube...@suse.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 <mkube...@suse.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.gf29...@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@lion:~> 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.
