[Buildroot] [RFC 00/11] common init infrastructure
Yann E. MORIN
yann.morin.1998 at free.fr
Sun Mar 22 11:28:07 UTC 2015
Alex, All,
On 2015-03-21 20:26 +0200, Alex Suykov spake thusly:
> This series is intended to clean up buildroot init system somewhat,
> removing the need for extensive sysv and systemd handling code
> in every package that installs init bits, and allowing alternative
> init systems to be implemented with reasonable amount of effort.
>
> Overview of the changes:
>
> * drop per-package sysv and systemd files, introduce common format
> used to generate files for both of them, use a script to do
> the conversion from common format to sysv or systemd.
I have not delve too deep in the implementation (because, Python! ;-) ),
but from the examples, it seems it would still be possible to start more
than one "daemon" for a service, like is done by samba, right?
> * remove sysv and systemd installation code from package .mk files,
> let pkg-generic handle it.
>
> * remove sysv-specific files from skeleton, and sysv-specific hacks
> from system/system.mk. Use a dedicated script to write inittab,
> handling global conditionals (root rw/ro, serial getty and so on)
>
> * remove user definitions from package .mk files, and mkdirs from
> per-package sysv initscript, use per-package .users and .files
> instead in a way similar to .hash files.
How do you handle conditional creation of users/groups? Let's take a
supposed package that can install a server and/or a client (like a SQL
related package, for example). The server (sqld) needs a specific
user+group, but the client (sql-cli) does not. Currently, this is easily
done by emclosing the user defintion between a 'if server' block.
> Expected benefits:
>
> * (almost) all packages get both sysv and systemd files at the same
> time and without the need to support them separately.
>
> * init-related changes can be introduced without patching
> all 70+ individual packages that install startup files.
>
> * new init systems can be introduced with only minor effort,
> including lightweight ones with controlled (foreground) daemons.
>
> This series includes the infrastructure changes, and a couple of
> package patches to show how it looks like. Complete set of package
> patches uploaded here: https://github.com/arsv/br/
It would be much nicer if you were to push your branch there, rather
than a set of patches. Having a branch would mean we could fetch from
it.
> This series is for reviewing, not for merging.
One thing that is wrong throughout the series, is that you hard-code the
path to "outoput/" and this breaks out-of-tree builds [0]. You should use
$(BASE_DIR) instead.
[0] http://buildroot.net/downloads/manual/manual.html#_building_out_of_tree
Also, I think this series is changing a lot of different things at the
same time. For example, there is infra changes to handle:
- init script,
- users/groups,
- skeleton /etc/ stuff
This series should be split in simpler sub-series, or at least into much
simpler patches. For example, patch 4/11 that adds help entries to init
systems could probably sent first (after a bit of rewording to remove
references to the new init infra), because it is a valuable addition,
and it does not really depend on the new infra.
Otherwise, I have a feeling this is pushing things a bit too far. I'm
usually very happy with "abstraction" and I more than once have pushed
for such changes. However, in this area, I'm a bit sceptic as to whether
we should introduce our own "initscript" format (the '.run' files).
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| 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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list