On Thu, Feb 03, 2022 at 08:20:10AM +0100, Martin Wilck wrote:
> On Wed, 2022-02-02 at 18:37 -0600, Benjamin Marzinski wrote:
> > On Wed, Feb 02, 2022 at 12:40:23AM +0100, mwilck@xxxxxxxx wrote:
> > > From: Martin Wilck <mwilck@xxxxxxxx>
> > >
> > > The kernel's autoload mechanism for SCSI device handlers doesn't
> > > work during SCSI device probing. While it's possible to load and
> > > attach device handlers after probing, it has disadvantages: the
> > > handlers are useful for error handling even before multipathd has
> > > started, and at least up to kernel 5.17, the sysfs "access_state"
> > > attribute
> > > will remain invisible for already probed devices.
> > >
> > > Distributions will therefore want to make sure the handlers are
> > > either
> > > built-in in the kernel, or loaded early. Add functionality to
> > > create and install a modules-load.d file with a list of handlers
> > > to load. By default, the list is empty, and no file will be
> > > generated.
> > > The list can be specified at install-time like this:
> > >
> > > make SCSI_DH_MODULES_PRELOAD="scsi_dh_rdac scsi_dh_emc" install
> > >
> > > dracut automatically adds modules-load.d files and the modules they
> > > reference to the initramfs.
> > >
> > > Note: distributions that compile scsi_mod as a module may rather
> > > want
> > > to use a modprobe.d file with a statement like this:
> > >
> > > softdep scsi_mod post: scsi_dh_alua scsi_dh_rdac
> > >
> >
> > I think you might need a default scsi_dh.conf file with a comment
> > header
> > or something. install won't install a file that doesn't exist. Or am
> > I
> > missing something here?
>
> Yes, you would need a conf file. But we can't construct it in the
> upstream code. It depends on how the distro compiles the SCSI modules.
> softdeps don't work with built-in modules, and with current kmod, there
> can be only one softdep directive per module (no stacking) [1]; thus if
> the distro (or the admin) needs further softdeps for scsi_mod, the
> directives would need to be merged into one, which is tricky to
> automate.
>
> The advantage of the softdep over modules-load.d is that it avoids
> loading the device handlers for systems without SCSI (like NVMe
> laptops, or embedded devices). The distro needs to decide whether or
> not that's worth it.
>
> On the contrary, the modules-load.d file stacks nicely with other
> packages.
Right, but having a default scsi_dh.conf file that just has a comment
header explaining what it is won't make anything get installed to
modules-load.d by default. You already made that install command
conditional. It just means that running
make SCSI_DH_MODULES_PRELOAD="scsi_dh_rdac scsi_dh_emc" install
will succeed, and give you a scsi_dh.conf in the modules-load.d
directory that loads those modules, instead of failing because there is
no scsi_dh.conf file to install. If you're against having a default
scsi_dh.conf for install to work with, I suppose another option would be
add the modules to scsi_dh.conf first, and then install it. Something
like
ifneq ($(SCSI_DH_MODULES_PRELOAD),)
> scsi_dh.conf
for _x in $(SCSI_DH_MODULES_PRELOAD); do echo "$$_x"; done \
>>scsi_dh.conf
$(INSTALL_PROGRAM) -m 644 scsi_dh.conf $(DESTDIR)$(modulesloaddir)/scsi_dh.conf
endif
But you have to truncate or remove the local copy of scsi_dh.conf first,
otherwise you would just keep adding the same modules on to the end.
This would mean that distros can't make their own custom scsi_dh.conf.
It would just be generated.
If none of this seems o.k. to you, at the very least you should change
the commit message to metion that
make SCSI_DH_MODULES_PRELOAD="scsi_dh_rdac scsi_dh_emc" install
will only work if you've already created a file named scsi_dh.conf in
the multipath directory.
-Ben
>
> Regards,
> Martin
>
> [1] https://www.spinics.net/lists/linux-modules/msg01654.html
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
