All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Thierry Bultel <thierry.bultel@linatsea.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3 2/3] package/dracut: new host package
Date: Thu, 6 Jan 2022 00:16:54 +0100	[thread overview]
Message-ID: <20220105231654.GL614810@scaer> (raw)
In-Reply-To: <20211223111348.3532601-2-thierry.bultel@linatsea.fr>

Thierry, All,

On 2021-12-23 12:13 +0100, Thierry Bultel spake thusly:
> dracut is the tool used by desktop distributions to
> build initrds. In the embedded world, it can be
> very usefull, too, for instance when wanting to
> create an initramfs for a system recovery mode.
> Whereas it is definitively possible to achieve
> this with buildroot, the process is to have a
> dedicated buildroot configuration for that,
> and perform a full build. Instead of doing that,
> the idea is to use dracut to pick the needed
> binaries/shared libraries, configuration files,
> or kernel modules from the 'target' directory.
> The advantage is to save build time, and also
> to have a consistency between the packages versions
> taken for the recovery and the production filesystem.

Please, wrap your commit log to ~72 chars.

> Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
> ---
[--SNIP--]
> diff --git a/package/dracut/05busybox-buildroot/module-setup.sh b/package/dracut/05busybox-buildroot/module-setup.sh
> new file mode 100755
> index 0000000000..b227571db4
> --- /dev/null
> +++ b/package/dracut/05busybox-buildroot/module-setup.sh

You will have to (briefly, maybe) explain how those 'modules' are meant
to be used...

> @@ -0,0 +1,69 @@
> +#!/bin/bash

... here you make it an executable (0755) shell script, but it only
defines functions, it actually calls nothing. Are moduels supposed to be
source-d from dracut itself?

> +check() {
> +	require_binaries \
> +		busybox | return 1

This can't possibly work: it will always fail (there is a single pipe,
so the whole command will fail).

Then what happens depends on whether the shell is set -e or not. If it
is not set -e, the execution continues, and the check() function will
always return 0 (success). If the shell is set -e, then execution of
check() ends right there, and presumably check() is called as an
if-block condition, and thus the condition will never be true.

So, it was not tested? ;-)

(also: commands that fit on a line should be on a single line, like so:
    require_binaries busybox || return 1
)

> +	return 0
> +}
> +
> +depends() {
> +	return 0
> +}
> +
> +
> +install_busybox_links() {
> +	dir=$1
> +	linkname=$2
> +
> +	(cd "$dracutsysrootdir"$dir &&

    $ shellcheck package/dracut/05busybox-buildroot/module-setup.sh
        (cd "$dracutsysrootdir"$dir &&
                               ^--^ SC2086: Double quote to prevent globbing and word splitting.

Also, please do variable expansion with curly braces (everywhere):

    "${dracutsysrootdir}${dir}"

> +	for x in *; do
> +	    if [ "$(readlink "$x")" = $linkname ]; then
> +	    	ln -sf $linkname $initdir/$dir/$x
> +	    fi
> +	done
> +	)
> +
> +}
> +
> +install() {
> +

No initial empty line at begining of function.

[--SNIP--]
> +#	mkdir -p $initdir/etc/init.d
> +#	cp -a $dracutsysrootdir/etc/init.d/* $initdir/etc/init.d

Commented-out debug code or non-function code should just be removed.

> +	

No empty line at the end of function.

> +}
> +
> diff --git a/package/dracut/06uclibc/module-setup.sh b/package/dracut/06uclibc/module-setup.sh
> new file mode 100644
> index 0000000000..77e9bd864e
> --- /dev/null
> +++ b/package/dracut/06uclibc/module-setup.sh
> @@ -0,0 +1,20 @@
> +#!/bin/bash
> +
> +check() {
> +	return 0
> +}
> +
> +depends() {
> +	return 0
> +}
> +
> +
> +
> +install() {
> +
> +	# Despite of the fact that the listed dependency (reported by readelf -d)
> +	# is purely ld-uClibc.so.1, the loader needs the ld-uClibc.so.0, too
> +
> +	ln -s ld-uClibc.so.1 $initdir/lib/ld-uClibc.so.0
> +

Extra empty lines...

But still, a little explanations (in the commit log) on how those
scripts are supposed to be used would help further review.

[--SNIP--]
> diff --git a/package/dracut/dracut.mk b/package/dracut/dracut.mk
> new file mode 100644
> index 0000000000..6c82b4ba75
> --- /dev/null
> +++ b/package/dracut/dracut.mk
> @@ -0,0 +1,45 @@
> +################################################################################
> +#
> +# dracut
> +#
> +################################################################################
> +
> +DRACUT_VERSION = 055
> +DRACUT_SOURCE = dracut-$(DRACUT_VERSION).tar.xz
> +DRACUT_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/boot/dracut
> +DRACUT_LICENSE = GPL-2.0
> +DRACUT_LICENSE_FILES = COPYING
> +
> +HOST_DRACUT_DEPENDENCIES += host-pkgconf host-kmod host-cross-ldd

First assignment should not be +=, but just =.

> +define HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
> +	$(SED) '/unset LD_LIBRARY_PATH/d' $(HOST_DIR)/bin/dracut
> +	$(SED) '/unset LD_PRELOAD/d' $(HOST_DIR)/bin/dracut

As for cross-ldd, we prefer that patching be done with actual patches
rather than sed expressions.

> +endef
> +
> +define HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT
> +	$(INSTALL) -D -m 0755 package/dracut/dracut_wrapper.sh \
> +		$(HOST_DIR)/usr/bin/dracut_wrapper.sh

Your commit log does not explain the reason why we need to have a
wrapper, or how it is going to be used...

Usually, when we introduce a wrapper, it replace sthe original
executable in name, and the original is renamed, with the wrapper
eventually calling into the renamed original...

So having a wrapper installed as you do it is slightly off-road...

> +endef
> +
> +ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
> +define HOST_DRACUT_POST_INSTALL_UCLIBC_MODULE
> +	$(INSTALL) -D -m 0755 package/dracut/06uclibc/module-setup.sh \
> +		$(HOST_DIR)/lib/dracut/modules.d/06uclibc/module-setup.sh
> +endef
> +HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_UCLIBC_MODULE
> +endif

And what about glibc? musl?

Can we unconditionally install the modules and change their check()
functions to decide whther the moduels is usable or not? Or something
else dynamic?

> +ifeq ($(BR2_INIT_BUSYBOX),y)
> +define HOST_DRACUT_POST_INSTALL_BUSYBOX_MODULE
> +	$(INSTALL) -D -m 0755 package/dracut/05busybox-buildroot/module-setup.sh \
> +		$(HOST_DIR)/lib/dracut/modules.d/05busybox-buildroot/module-setup.sh
> +endef
> +HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_BUSYBOX_MODULE

And what about systemd as an init system? openrc? sysv-init? Others?

> +endif
> +
> +HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
> +HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT

Spaces around the operator. Also, since this is the same hook, a single
assignment is better:

    HOST_DRACUT_POST_INSTALL_HOOKS += \
        HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT \
        HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT

Note: we prefer to have uncondtional asignemnts come before the
conditional ones, and we also prefer to have ythe hook assignment
come right after the hook definitionm like so:


    define HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
        blabla
    endef
    HOST_DRACUT_POST_INSTALL_HOOKS = HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT

    define HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT
        blabla
    endef
    HOST_DRACUT_POST_INSTALL_HOOKS += HOST_DRACUT_POST_INSTALL_WRAPPER_SCRIPT

    ifeq ($(BR2_INIT_BUSYBOX),y)
    define HOST_DRACUT_POST_INSTALL_BUSYBOX_MODULE
        blabla
    endef
    HOST_DRACUT_POST_INSTALL_HOOKS += HOST_DRACUT_POST_INSTALL_BUSYBOX_MODULE
    endif

and so on...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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

  reply	other threads:[~2022-01-05 23:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23 11:13 [Buildroot] [PATCH v3 1/3] package/cross-ldd: new package Thierry Bultel
2021-12-23 11:13 ` [Buildroot] [PATCH v3 2/3] package/dracut: new host package Thierry Bultel
2022-01-05 23:16   ` Yann E. MORIN [this message]
2022-01-06 14:56     ` Thierry Bultel
2022-01-06 15:13       ` Thomas Petazzoni
2022-01-06 15:56         ` Thierry Bultel
2021-12-23 11:13 ` [Buildroot] [PATCH v3 3/3] fs/cpio: new option to use dracut tool Thierry Bultel
2022-01-06 10:31   ` Yann E. MORIN
2022-01-06 13:48     ` Thierry Bultel
2022-01-05 22:29 ` [Buildroot] [PATCH v3 1/3] package/cross-ldd: new package Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220105231654.GL614810@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=thierry.bultel@linatsea.fr \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.