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
Attachment:
signature.asc
Description: PGP signature
