Re: [Buildroot] [PATCH 2/4] package/dracut: allow users to provide their own modules

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Arnout, All,

On 2022-09-17 22:17 +0200, Arnout Vandecappelle spake thusly:
> On 19/08/2022 19:50, Yann E. MORIN wrote:
> >Dracut modules can only be looked for in HOST_DIR/lib/dracut/modules.d/
> >and dracut does not offer the possibility to look elsewhere.
> >
> >Installing files in HOST_DIR/ can do done either from a host-package, or
> >via a post-built script; there is no overlay like there is for target/.
> >This is a bit cumbersome.
> >
> >Add an option to the host-dracut package, so users can point to a list
> >of modules to install.
[--SNIP--]
>  Although I agree that conceptually this extra modules thing belongs with
> the dracut package itself, from a user, practical point of view, you
> actually want it in the dracut option of fs/cpio. If you use host-dracut
> without the cpio-dracut fs, it means you are using it in a post-build
> script, so it's not so weird to also install the extra modules in that
> script. On the other hand, if you are using cpio-dracut and you need extra
> modules (which is quite likely), then it extremely annoying that you have to
> go first to filesystems->cpio and later to hosttools->dracut...
> 
>  In other words, I think this should be moved to cpio.

I beg to differ (of course!). ;-)

Extra modules change the features of dracut; they change what dracut can
do. They are not like config files, which actually describe what the
filesystem is to be assemble from.

Besides copying extra modules as done in this patch, a user could also
patch dracut to add those modules. So, semantically, extra modules from
a patch or a local directory are the same.

When adding new modules, you will indeed have to add config files that
reference them (or one of your config files already references one and
you missed it). Probably, indeed, the modules will be developped in a
more-or-less closed loop with the config files that use them; but that's
incidental.

If they were part of the cpio filesystem, they'd be copied on every
invocation, though, which is conceptually not very nice either (but
probably very low overhead).

Finally, even if using from a post-build script, it is still nicer to
expose that option in the menuconfig, rather than require the user to do
the copy in their script.

So, local modules should really belong to the dracut package, not the
cpio filesystem.

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> >+
> >+endif
> >diff --git a/package/dracut/dracut.mk b/package/dracut/dracut.mk
> >index 2b6a144aac..96fa7db6ba 100644
> >--- a/package/dracut/dracut.mk
> >+++ b/package/dracut/dracut.mk
> >@@ -19,6 +19,15 @@ define HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT
> >  endef
> >  HOST_DRACUT_POST_INSTALL_HOOKS += HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT
> >+HOST_DRACUT_EXTRA_MODULES = $(call qstrip,$(BR2_PACKAGE_HOST_DRACUT_EXTRA_MODULES))
> >+define HOST_DRACUT_INSTALL_EXTRA_MODULES
> >+	$(Q)mkdir -p $(HOST_DIR)/lib/dracut/modules.d/
> >+	$(foreach m,$(HOST_DRACUT_EXTRA_MODULES), \
> >+		cp -a $(m)/* $(HOST_DIR)/lib/dracut/modules.d/
> >+	)
> >+endef
> >+HOST_DRACUT_POST_INSTALL_HOOKS += HOST_DRACUT_INSTALL_EXTRA_MODULES
> >+
> >  # When using uClibc or musl, there must be "ld-uClibc.so.1" or
> >  # "ld-musl-x.so" symlinks, respectively - else the init process cannot
> >  # start

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot