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