On Sun, Mar 10, 2019 at 05:50:38PM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> On 3/10/19 10:51 AM, Leon Romanovsky wrote:
> > On Wed, Mar 06, 2019 at 07:38:05PM +0200, Leon Romanovsky wrote:
> >> On Wed, Mar 06, 2019 at 06:20:18PM +0100, Nicolas Morey-Chaisemartin wrote:
> >>>
> >>> On 3/6/19 6:13 PM, Leon Romanovsky wrote:
> >>>> On Wed, Mar 06, 2019 at 05:11:59PM +0100, Nicolas Morey-Chaisemartin wrote:
> >>>>> On 3/6/19 11:08 AM, Leon Romanovsky wrote:
> >>>>>> From: Leon Romanovsky <leonro@xxxxxxxxxxxx>
> >>>>>>
> >>>>>> Generalize the naming scheme for RDMA devices, so users will always
> >>>>>> see names based on topology/GUID information. Such naming scheme has
> >>>>>> big advantage that the names are fully automatic, fully predictable
> >>>>>> and they stay fixed even if hardware is added or removed (i.e. no
> >>>>>> reenumeration takes place) and that broken hardware can be replaced
> >>>>>> seamlessly.
> >>>>>>
> >>>>>> The naming policy is possible to chose from NAME_KERNEL, NAME_PCI,
> >>>>>> NAME_GUID or NAME_FALLBACK, which is controlled by udev rule.
> >>>>>>
> >>>>>> * NAME_KERNEL - don't change names and rely on kernel assignment. This
> >>>>>> will keep RDMA names as before. Example: "mlx5_0".
> >>>>>> * NAME_PCI - read PCI location and topology as a source for stable names,
> >>>>>> which won't change in any software event (reset, PCI probe e.t.c.).
> >>>>>> Example: "mlxp0s12f4".
> >>>>>> * NAME_GUID - read system image GUID information in simillar manner to
> >>>>>> net MAC naming policy. Example "mlxx525400c0fe123455".
> >>>>>> * NAME_FALLBACK - automatic fallback: NAME_PCI->NAME_GUID->NAME_KERNEL
> >>>>>>
> >>>>>> No doubts that new names are harder to read than the "mlx5_0" everybody,
> >>>>>> is used to, but being consistent in scripts is much more important.
> >>>>>>
> >>>>>> As a matter of precaution, we set default naming policy to be
> >>>>>> NAME_KERNEL, but will change it later to NAME_FALLBACK.
> >>>>>>
> >>>>> You probably should extend udev.md to document this value (with pretty much a copy of your commit message).
> >>>> I will do, just wanted to be sure that we are agree on the implementation.
> >>>>> Also, not sure coding this value directly into the udev script is the right thing to do.
> >>>>> At least RPM may mess with you file during an update if you change it.
> >>>>> We already have a /etc/rdma with a bunch of stuff. Could we stick in there too ?
> >>>> I did it to be similar to other /usr/lib/udev/rules.d/60-persistent-*.rules files.
> >>>> Users who are needed to overwrite it, are expected to use systemd and
> >>>> create their local rule in /etc/udev/rules.d/.
> >>> You're right. In that case, patch #5 needs to use %config(noreplace) %{_sysconfdir}/udev/rules.d/ (same as ipoib persistent) so RPM won't mess it up.
> >> Thanks, I'll change.
> > I started to change it and realized that there is misunderstanding.
> > There is no need to install this udev rule in /etc/udev/rules.d/,
> > because users will write their own rules with higher numbers XX-*.rules
> > to ensure that they are executing last and not change "default" rule.
> >
> > Thanks
>
> IMHO, it feels slightly weird to add a secondary udev rule to change the naming scheme.
> The persistent-*.rules are (from what I see on my system) dedicated to give a specific name to a specific interface.
> Here, we just want to change the global setting. And adding a new rule means we will rename all interfaces twice.
Nicolas,
It is not how UDEV rules are working, those rules will be READ twice,
but executed only last rule due to usage of "=" and not "+=" and
explicit "PROGRAM" and not "RUN" directives.
>
> I'm pretty sure users will directly change the rule file provided by the RPM and get their setup messed with during update.
> I would say either:
> - Do what is needed to make this file a "config" file so it can be changed
> - Add a large and unmissable WARNING in the rule file so that there is a small chance the user will read it and add its own instead of modifying this one.
>
> Nicolas
>
Attachment:
signature.asc
Description: PGP signature
