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

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Damien Le Moal <dlemoal@kernel.org>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	linux-amarula@amarulasolutions.com, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3 1/3] package/tinyinit: new package
Date: Thu, 29 Aug 2024 23:47:37 +0200	[thread overview]
Message-ID: <20240829234737.38039ef5@windsurf> (raw)
In-Reply-To: <Zs4x6LWMJfdWqApz@landeda>

On Tue, 27 Aug 2024 22:07:04 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > # Packages that provide commands that may also be busybox applets:
> > BUSYBOX_DEPENDENCIES = \
> > 	...
> > 	$(if $(BR2_PACKAGE_TINYINIT),tinyinit) \  
> 
> Good catch! We also need that for tini, then.

Yes.

> > > +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?  
> 
> As Dario already pointed out, that was my suggestion to drop it from the
> init selection.
> 
> The reasoning is that we need to know the init system when we need some
> infra for it. For example, for busybox/sysvinit, we need to install init
> scripts, for systemd, the units, and for openrc, the openrc "units".
> 
> And the "None" init choice really is "Custom", in that there is always a
> PID-1 process, whether in a real system, a VM, or a container: it is the
> first process that is started in that environment. Now, whether that
> process is a real init system, a stub, or directly the final applicaiton,
> it is still a PID-1, and thus treated as 'init' by the kernel.
> 
> The existing tini package is to be used a a PID-1 in containers (I use
> it extensively in that situation) and it does not need any infra in
> Buildroot (it can only spawn a single child and is a reaper); to my
> eyes, tiny-init is also very simple and does not require any infra in
> Buildroot. Both tini and tiny-init are cases for a "Custom" init
> (currently labelled "None").

I understand your point, but:

(1) It is really unclear for the user that they have to chose "None" as
    init to be able to use tinyinit (tinyinit is proposed with depends
    on BR2_INIT_NONE)

(2) Due to (1), Dario has added a "tinyinit needs BR2_INIT_NONE, i. e.
    no init system installed" Config.in comment, which I also find odd

So while I understand your point that tinyinit or tini don't need as
much infrastructure/logic as busybox init/sysvinit/systemd/openrc, I
find the current way they are presented to be very weird (but I can
live with it).

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