On Mon, Aug 12, 2019 at 08:21:31AM -0700, Roopa Prabhu wrote: > On Sun, Aug 11, 2019 at 3:10 PM Michal Kubecek <mkube...@suse.cz> wrote: > > > > Not all of them are hardware based, there are also links based on > > filesystem label or UUID. But my point is rather that udev creates > > multiple links so that any of them can be used in any place where > > a block device is to be identified. > > > > As network devices can have only one name, udev drops kernel provided > > name completely and replaces it with name following one naming scheme. > > Thus we have to know which naming scheme is going to be used and make > > sure it does not change. With multiple alternative names, we could also > > have all udev provided names at once (and also the original one from > > kernel). > > ok, understand the use-case. > But, Its hard for me to understand how udev is going to manage this > list of names without structure to them. > Plus how is udev going to distinguish its own names from user given name ?. > > I thought this list was giving an opportunity to use the long name > everywhere else. > But if this is going to be managed by udev with a bunch of structured > names, I don't understand how the rest of the system is going to use > these names. > > Maybe we should just call this a udev managed list of names. > > (again, i think the best way to do this for udev is to provide the > symlink like facility via devlink or any other infra).
I certainly didn't want to suggest for alternative names to be managed by udev. What I meant was that supporting multiple alternative names would allow udev to create its names based on e.g. device bus address, BIOS/UEFI slot number, MAC address etc. But it would still be up to admins if they want to create their own names. Michal
