From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] help entries for Init system config menu
Date: Wed, 8 Apr 2015 23:12:43 +0200 [thread overview]
Message-ID: <20150408211243.GD4197@free.fr> (raw)
In-Reply-To: <20150324202302.GA4645@vostro>
Alex, All,
On 2015-03-24 22:23 +0200, Alex Suykov spake thusly:
> Primary focus is on (auto-)respawning and runtime control.
>
> Systemd entry describes current state, with several daemons
> configured as forking.
I think this is going a bit too far.
People buildign a system from scratch are expected to have at least some
knowledge about what ehy're doing, especially with regard to the init
system.
Sicne this will never be a complete description (especially the systemd
one as it gets more features), we'd be lagging behind quite fast.
So, I'm not too fond of this...
Regards,
Yann E. MORIN.
> Signed-off-by: Alex Suykov <alex.suykov@gmail.com>
> ---
> Patch split from the series since it does not depend on any
> of the changes there.
>
> system/Config.in | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/system/Config.in b/system/Config.in
> index 9973cc2..59c759a 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -75,15 +75,40 @@ config BR2_TARGET_GENERIC_PASSWD_METHOD
> choice
> prompt "Init system"
> default BR2_INIT_BUSYBOX
> + help
> + Upon bootup, kernel spawns init and init is expected
> + to spawn anything else.
> +
> + Buildroot supports several alternative init implementations
> + providing varying degrees of control over the spawned processes.
>
> config BR2_INIT_BUSYBOX
> bool "BusyBox"
> select BR2_PACKAGE_BUSYBOX
> + help
> + Minimalistic init implementation from busybox
> + with systemV-style init scripts.
> +
> + Runlevels are not supported.
> +
> + Daemons are started in background using scripts
> + from /etc/init.d. Failed processes are not respawned.
> + Pid files provide some control over running processes.
>
> config BR2_INIT_SYSV
> bool "systemV"
> select BR2_PACKAGE_BUSYBOX_SHOW_OTHERS # sysvinit
> select BR2_PACKAGE_SYSVINIT
> + help
> + System V init, probably the best-known init implementation
> + in Linux, with simplified SysV-style initscripts.
> +
> + Supports runlevels, but buildroot does not use them.
> + The system boots into the default runlevel and stays there.
> +
> + Daemons are started in background using scripts
> + from /etc/init.d. Failed processes are not respawned.
> + Pid files provide some control over running processes.
>
> config BR2_INIT_SYSTEMD
> bool "systemd"
> @@ -98,6 +123,29 @@ config BR2_INIT_SYSTEMD
> depends on !BR2_STATIC_LIBS
> depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
> select BR2_PACKAGE_SYSTEMD
> + help
> + systemd is more that just an init implementation.
> + It is a composite package handling most aspects
> + of system initialization and daemon supervision.
> +
> + Systemd uses arbitrary-named "targets" instead
> + of systemV-style runlevels. Daemons may be stopped
> + and restarted using systemctl command. If configured
> + so, failed processes are respawned.
> +
> + Whenever possible, package-supplied service files
> + are used. Some daemons are configured to run in
> + foreground and some run as background processes.
> +
> + Due its pervasiveness and extensive feature range,
> + choosing systemd shapes the rest of the system.
> + A systemd-based buildroot will differ little
> + from any major systemd-based Linux distribution
> + in pretty much any aspects of the boot process,
> + initialization, runtime configuration and process
> + supervision.
> +
> + Beware of its large size and numerous dependencies.
>
> comment 'systemd needs an (e)glibc toolchain, headers >= 3.7'
> depends on !(BR2_TOOLCHAIN_USES_GLIBC \
> @@ -105,6 +153,12 @@ comment 'systemd needs an (e)glibc toolchain, headers >= 3.7'
>
> config BR2_INIT_NONE
> bool "None"
> + help
> + Do not install any kind of init system.
> +
> + Make sure your initrd and/or root fs skeleton provide
> + some executable for kernel to start, otherwise
> + the system will panic at boot.
>
> endchoice
>
> --
> 2.0.3
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2015-04-08 21:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 20:23 [Buildroot] [PATCH] help entries for Init system config menu Alex Suykov
2015-04-08 21:12 ` Yann E. MORIN [this message]
2015-10-18 21:46 ` Thomas Petazzoni
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=20150408211243.GD4197@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox