[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJieiUhcG6tpDA3evMtiyPSsKS9bfKPeD=dUO70oYOgGbFKy9Q@mail.gmail.com>
Date: Sat, 10 Aug 2019 06:46:57 -0700
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
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 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.
No strong objections around multiple alternate names as long as the
need for this does not make the base long name setting complex :).
Powered by blists - more mailing lists