Re: [Buildroot] [PATCH v3 1/3] package/tinyinit: new package

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

On Thu, 22 Aug 2024 20:37:40 +0200
Dario Binacchi <dario.binacchi@amarulasolutions.com> wrote:

>  DEVELOPERS                   |  1 +
>  package/Config.in            |  1 +
>  package/tinyinit/Config.in   | 10 ++++++++++
>  package/tinyinit/init        | 32 ++++++++++++++++++++++++++++++++
>  package/tinyinit/tinyinit.mk | 12 ++++++++++++
>  5 files changed, 56 insertions(+)

We also need to change busybox.mk to ensure that tinyinit is built
before Busybox:

# Packages that provide commands that may also be busybox applets:
BUSYBOX_DEPENDENCIES = \
	...
	$(if $(BR2_PACKAGE_TINYINIT),tinyinit) \


> diff --git a/package/tinyinit/Config.in b/package/tinyinit/Config.in
> new file mode 100644
> index 000000000000..2ceb8e191e23
> --- /dev/null
> +++ b/package/tinyinit/Config.in
> @@ -0,0 +1,10 @@
> +config BR2_PACKAGE_TINYINIT
> +	bool "tinyinit"
> +	depends on BR2_INIT_NONE
> +	help
> +	  A Linux tiny initialization script suitable for resource
> +	  limited systems, which can be used as an alternative to the
> +	  one provided by Busybox.
> +
> +comment "tinyinit needs BR2_INIT_NONE, i. e. no init system installed"
> +	depends on !BR2_INIT_NONE

I find this a bit odd. In the end, shouldn't we simply promote tinyinit
as an init implementation, and have its own BR2_INIT_TINYINIT entry?

Also, should BR2_PACKAGE_TINYINIT select busybox? Or do we pretend that
it is possible to use it with some other implementations of mount and
other basic commands? Perhaps this is a good case to use "imply
BR2_PACKAGE_BUSYBOX", so that BR2_PACKAGE_TINYINIT enables busybox by
default, but still allows removing busybox if really the user knows
what (s)he is doing?

> +define TINYINIT_INSTALL_TARGET_CMDS
> +	$(INSTALL) -m 0755 -D $(TINYINIT_PKGDIR)/init $(TARGET_DIR)/sbin/init
> +	(cd $(TARGET_DIR); ln -sf /sbin/init init)

Hmm. I initially thought this symlink shouldn't be needed, as it's
created by fs/cpio/cpio.mk when you're building a cpio for initramfs:

ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)

define ROOTFS_CPIO_ADD_INIT
        if [ ! -e $(TARGET_DIR)/init ]; then \
                ln -sf sbin/init $(TARGET_DIR)/init; \
        fi
endef

else
# devtmpfs does not get automounted when initramfs is used.
# Add a pre-init script to mount it before running init
# We must have /dev/console very early, even before /init runs,
# for stdin/stdout/stderr
define ROOTFS_CPIO_ADD_INIT
        if [ ! -e $(TARGET_DIR)/init ]; then \
                $(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
        fi
        mkdir -p $(TARGET_DIR)/dev
        mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
endef

But actually, in the case of a non-static /dev, it doesn't do a
symlink, but adds a pre-init script, and your tinyinit already does the
tasks of this pre-init provided by fs/cpio/init.

So I guess what you did is probably OK, but maybe a comment would be
useful. The only downside of your approach is that it leaves a /init
symlink that isn't used/needed for non-initramfs use-cases, but perhaps
that's OK.


Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot