| Message ID | 212daefb880a3c5e49ff4aa8278cc4c3bc67360e.1660931225.git.yann.morin.1998@free.fr |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | dracut: extend support and tests (branch yem/dracut) | expand |
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. > > Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> > Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > Cc: Thierry Bultel <thierry.bultel@linatsea.fr> > Cc: Adam Duskett <aduskett@gmail.com> > --- > package/dracut/Config.in.host | 11 +++++++++++ > package/dracut/dracut.mk | 9 +++++++++ > 2 files changed, 20 insertions(+) > > diff --git a/package/dracut/Config.in.host b/package/dracut/Config.in.host > index 18f562b310..5756dbd43f 100644 > --- a/package/dracut/Config.in.host > +++ b/package/dracut/Config.in.host > @@ -7,3 +7,14 @@ config BR2_PACKAGE_HOST_DRACUT > and combining it with the dracut framework. > > https://dracut.wiki.kernel.org > + > +if BR2_PACKAGE_HOST_DRACUT > + > +config BR2_PACKAGE_HOST_DRACUT_EXTRA_MODULES > + string "extra dracut modules" > + help > + Space-separated list of directories containing dracut modules > + to install. The modules will be installed alongside the ones > + bundled with dracut. 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. 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
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
On 17/09/2022 23:19, Yann E. MORIN wrote: > 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. There's no question that semantically they belong with host-dracut. That's why I wrote "conceptually they belong with the dracut package". However, looking at it from a usability point of view, that is no longer the case. In the head of the developer, what they want to do is to make sure the right stuff ends up in their cpio archive. They don't actually care if the dracut package is used for that. Perhaps compare it with the gcc and libc options: we put them in the toolchains menu, even though they actually belong to the gcc/uclibc packages. A middle ground would be to duplicate the option, having one in the host-dracut package that has the one from the cpio fs as the default. > 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. From the user point of view, that's pretty essential, not just 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). I was actually thinking of just putting the menu entry there, but keep the logic in dracut.mk. Again, similar to how we do it for gcc (although there we have the actual menu in package/gcc as well). > 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. That is true. Regards, Arnout > 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 >
Arnout, All, On 2022-09-18 10:57 +0200, Arnout Vandecappelle spake thusly: > On 17/09/2022 23:19, Yann E. MORIN wrote: > >On 2022-09-17 22:17 +0200, Arnout Vandecappelle spake thusly: > >>On 19/08/2022 19:50, Yann E. MORIN wrote: > >>>Add an option to the host-dracut package, so users can point to a list > >>>of modules to install. [--SNIP--] > >> In other words, I think this should be moved to cpio. > >I beg to differ (of course!). ;-) [--SNIP--] > However, looking at it from a usability point of view, that is no longer > the case. In the head of the developer, what they want to do is to make sure > the right stuff ends up in their cpio archive. They don't actually care if > the dracut package is used for that. A final nail in the coffin of a host-dracut option, is that host-dracut is not user-selectable; the kconfig symbol does not have a prompt, and is only selectable by something else, like fs/cpio's dracut option. On another note, users who had a post-image script that uses dracut from before we introduced it, were obviously not using host-dracut, but a dracut from their host, and so they most probably can't use extra modules in that case, so we do not need to catter to those either. So, I'll resubmit as you suggested. Regards, Yann E. MORIN.
diff --git a/package/dracut/Config.in.host b/package/dracut/Config.in.host index 18f562b310..5756dbd43f 100644 --- a/package/dracut/Config.in.host +++ b/package/dracut/Config.in.host @@ -7,3 +7,14 @@ config BR2_PACKAGE_HOST_DRACUT and combining it with the dracut framework. https://dracut.wiki.kernel.org + +if BR2_PACKAGE_HOST_DRACUT + +config BR2_PACKAGE_HOST_DRACUT_EXTRA_MODULES + string "extra dracut modules" + help + Space-separated list of directories containing dracut modules + to install. The modules will be installed alongside the ones + bundled with dracut. + +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
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. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thierry Bultel <thierry.bultel@linatsea.fr> Cc: Adam Duskett <aduskett@gmail.com> --- package/dracut/Config.in.host | 11 +++++++++++ package/dracut/dracut.mk | 9 +++++++++ 2 files changed, 20 insertions(+)