Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)
cover Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)
Hello All!
Following up on Gustavo's proposal [0] on a clean up on our init scripts (and eventually our systemd unit files), here is an *RFC* series that tries to implement Gustavo's idea.
The series is split in four parts:
- patches 1-3 are preparatory work, and not much interesting in the
Grand Scheme of Life;
- patches 4-5 introduce a generated kconfig snippet, that contains the list of services for each enabled packages, that the user can enable/disable at will, directly from the menuconfig (for now, the default is that all services are disabled, that can be changed later);
- patch 6 is the guts that installs the service files:
- installs the service's startup script,
- enables/disables the service,
- installs the service's configuration, if it exists;
- patch 7 is just an example (with empty scripts) of how to declare services in a package.
To be noted:
- the code will need some revamp; this is just meant to be an RFC!
- only sysv init is handled for now
- this is by far incomplete even for the sysv case
- the /etc/config/ part has been left out for now; it would anyway most probably provided via a rootfs-overlay
- the manual part is missing
- there are typoes all over the place :-/
As usual: on your mark, get set, comment! ;-)
[0] http://lists.busybox.net/pipermail/buildroot/2015-March/121086.html
Regards,
Yann E. MORIN.
The following changes since commit a4788aa6157d1496cdd32cb9802710d4e97bc550:
btrfs-progs: bump to version 3.19 (2015-03-11 22:38:36 +0100)
are available in the git repository at:
git://git.busybox.net/~ymorin/git/buildroot yem/services
for you to fetch changes up to f2c8684c9a6cfa5cfe8d776ac8ce4693667c329f:
[NOT TO BE APPLIED] package/busybox: add afake services as example (2015-03-11 23:08:51 +0100)
----------------------------------------------------------------
Yann E. MORIN (7):
package infra: print the name of the package being parsed
Makefile: always scan packages' .mk files, even with no .config
Makefile: introduce a intermediate rule before the configurators
packages: introduce a generated kconfig snippet in the menuconfig
packages: generate services sub-menu
[INCOMPLETE] pkg-generic: act on enabled services
[NOT TO BE APPLIED] package/busybox: add afake services as example
Config.in | 4 +++ Makefile | 67 ++++++++++++++++++++++++++++---------------- package/Config.in | 2 ++ package/busybox/S98bar | 0 package/busybox/S99foo | 0 package/busybox/bar.defaults | 1 + package/busybox/busybox.mk | 2 ++ package/pkg-generic.mk | 28 ++++++++++++++++++ package/pkg-utils.mk | 3 ++ 9 files changed, 83 insertions(+), 24 deletions(-) create mode 100644 package/busybox/S98bar create mode 100644 package/busybox/S99foo create mode 100644 package/busybox/bar.defaults
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/7 package infra: print the name of the package being parsed
Currently, our start-up time is far from being null. This is because we have 1500 packages that may each define or amend north of 60 variables (either directly in their .mk, as well as through the package macros).
This is very harsh on make, which handles variables in hash tables.
So, our startup time can be up to a few seconds, and there is not much we can do about that.
What's even not very encouraging, is that there is no feedback to the user that we are actually doing something.
Just print a message for each package we scan, so the user is aware something is going on.
From a clean, out-of-tree directory, prepare with:
make $(pwd)/build/buildroot-config/{,m}confto have the configurators not impact the measurements. Then run in sequence:
before after
make help 0.201 0.202 make defconfig 0.260 0.263 make help 2.976 0.984 make oldconfig 0.260 0.271
(rough average of ~4 runs each)
For the first 'make help', there's no .config, and hence we do not scan the packages' .mk, and we are 'fast'. For the second 'make help', there is a .config file, and we scann all packages' .mk file, and we are 'slow'. This patch has no virtually impact on the time it takes to process the packages' .mk files.
--- Makefile | 6 ++++++ package/pkg-generic.mk | 3 +++ package/pkg-utils.mk | 3 +++ 3 files changed, 12 insertions(+)
Makefile +6 -0
@@ -372,6 +372,9 @@ ifneq ($(BR2_DEPRECATED),y) include Makefile.legacy endif +# Just print one line, as scanning packages rewinds one line back +$(info .) + include package/Makefile.in include support/dependencies/dependencies.mk
@@ -397,6 +400,9 @@ include fs/common.mk include $(BR2_EXTERNAL)/external.mk +# Clear last "Scanning package foo" line +$(info $(TERM_UP_KILL)Done scanning packages.) + TARGETS_SOURCE := $(patsubst %,%-source,$(TARGETS)) TARGETS_DIRCLEAN := $(patsubst %,%-dirclean,$(TARGETS))
package/pkg-generic.mk +3 -0
@@ -305,6 +305,9 @@ endef define inner-generic-package +# Inform user something is happening... +$$(info $(TERM_UP_KILL)Scanning package $(1)) + # Define default values for various package-related variables, if not # already defined. For some variables (version, source, site and # subdir), if they are undefined, we try to see if a variable without
package/pkg-utils.mk +3 -0
@@ -81,6 +81,9 @@ MESSAGE = echo "$(TERM_BOLD)>>> $($(PKG)_NAME) $($(PKG)_VERSION) $(call qstrip,$ TERM_BOLD := $(shell tput smso) TERM_RESET := $(shell tput rmso) +# Cursor one line up, start of line, erase line +TERM_UP_KILL := $(shell printf "\033[1A\r\033[K") + # Utility functions for 'find' # findfileclauses(filelist) => -name 'X' -o -name 'Y' findfileclauses = $(call notfirstword,$(patsubst %,-o -name '%',$(1)))
Signature · 1 line
1.9.1
PATCH 2/7 Makefile: always scan packages' .mk files, even with no .config
In reply to Yann E. MORINCurrently, we avoid scanning packages' .mk files when we have no .config file. This is an optimisation made to speed up bringing up the configurator on the first run.
In an up coming patch, we'll need to generate a Kconfig snippet from package-defined values, so they can define the "services" (aka daemons) they may install; we'll use that information to present this list of sercices to the user, so we need to scan all packages' .mk files, even on first run.
Narrow down the the conditional "all:" rule to the strictly required minimum.
--- Makefile | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
Makefile +2 -6
@@ -279,8 +279,6 @@ unexport RUBYOPT include package/pkg-utils.mk include package/doc-asciidoc.mk -ifeq ($(BR2_HAVE_DOT_CONFIG),y) - ################################################################################ # # Hide troublesome environment variables from sub processes
@@ -364,8 +362,6 @@ export BASE_DIR # ################################################################################ -all: world - # Include legacy before the other things, because package .mk files # may rely on it. ifneq ($(BR2_DEPRECATED),y)
@@ -685,10 +681,10 @@ graph-depends: graph-depends-requirements |tee $(BASE_DIR)/graphs/$(@).dot \ |dot $(BR2_GRAPH_DOT_OPTS) -T$(BR_GRAPH_OUT) -o $(BASE_DIR)/graphs/$(@).$(BR_GRAPH_OUT) +ifeq ($(BR2_HAVE_DOT_CONFIG),y) +all: world else # ifeq ($(BR2_HAVE_DOT_CONFIG),y) - all: menuconfig - endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y) # configuration
Signature · 1 line
1.9.1
PATCH 3/7 Makefile: introduce a intermediate rule before the configurators
In reply to Yann E. MORINCurrently, all configurators depend on generating the out-of-tree Makefile wrapper.
In an upcoming patch, we'll need to also generate a kconfig fragment, so it will have to kick in before we run the configurators.
Introduce a new intermediat "prepare-kconfig" rule, so we can commonalise the dependnecies of the confiurators. Move the dependency on the Makefile wrapper to that new intermediate rule.
--- Makefile | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-)
Makefile +20 -18
@@ -693,6 +693,8 @@ endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y) HOSTCFLAGS = $(CFLAGS_FOR_BUILD) export HOSTCFLAGS +prepare-kconfig: outputmakefile + $(BUILD_DIR)/buildroot-config/%onf: mkdir -p $(@D)/lxdialog PKG_CONFIG_PATH="$(HOST_PKG_CONFIG_PATH)" $(MAKE) CC="$(HOSTCC_NOCCACHE)" HOSTCC="$(HOSTCC_NOCCACHE)" \
@@ -710,43 +712,43 @@ COMMON_CONFIG_ENV = \ BR2_CONFIG=$(BR2_CONFIG) \ BR2_EXTERNAL=$(BR2_EXTERNAL) -xconfig: $(BUILD_DIR)/buildroot-config/qconf outputmakefile +xconfig: $(BUILD_DIR)/buildroot-config/qconf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN) -gconfig: $(BUILD_DIR)/buildroot-config/gconf outputmakefile +gconfig: $(BUILD_DIR)/buildroot-config/gconf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) srctree=$(TOPDIR) $< $(CONFIG_CONFIG_IN) -menuconfig: $(BUILD_DIR)/buildroot-config/mconf outputmakefile +menuconfig: $(BUILD_DIR)/buildroot-config/mconf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN) -nconfig: $(BUILD_DIR)/buildroot-config/nconf outputmakefile +nconfig: $(BUILD_DIR)/buildroot-config/nconf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN) -config: $(BUILD_DIR)/buildroot-config/conf outputmakefile +config: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN) -oldconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +oldconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --oldconfig $(CONFIG_CONFIG_IN) -randconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +randconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --randconfig $(CONFIG_CONFIG_IN) -allyesconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +allyesconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --allyesconfig $(CONFIG_CONFIG_IN) -allnoconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +allnoconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --allnoconfig $(CONFIG_CONFIG_IN) -randpackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +randpackageconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @grep -v BR2_PACKAGE_ $(BR2_CONFIG) > $(CONFIG_DIR)/.config.nopkg @grep '^config BR2_PACKAGE_' Config.in.legacy | \
@@ -757,7 +759,7 @@ randpackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile $< --randconfig $(CONFIG_CONFIG_IN) @rm -f $(CONFIG_DIR)/.config.nopkg -allyespackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +allyespackageconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @grep -v BR2_PACKAGE_ $(BR2_CONFIG) > $(CONFIG_DIR)/.config.nopkg @grep '^config BR2_PACKAGE_' Config.in.legacy | \
@@ -768,7 +770,7 @@ allyespackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile $< --allyesconfig $(CONFIG_CONFIG_IN) @rm -f $(CONFIG_DIR)/.config.nopkg -allnopackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +allnopackageconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @grep -v BR2_PACKAGE_ $(BR2_CONFIG) > $(CONFIG_DIR)/.config.nopkg @$(COMMON_CONFIG_ENV) \
@@ -776,30 +778,30 @@ allnopackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile $< --allnoconfig $(CONFIG_CONFIG_IN) @rm -f $(CONFIG_DIR)/.config.nopkg -silentoldconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +silentoldconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config $(COMMON_CONFIG_ENV) $< --silentoldconfig $(CONFIG_CONFIG_IN) -olddefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +olddefconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config $(COMMON_CONFIG_ENV) $< --olddefconfig $(CONFIG_CONFIG_IN) -defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +defconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --defconfig$(if $(DEFCONFIG),=$(DEFCONFIG)) $(CONFIG_CONFIG_IN) # Override the BR2_DEFCONFIG from COMMON_CONFIG_ENV with the new defconfig -%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(TOPDIR)/configs/%_defconfig outputmakefile +%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(TOPDIR)/configs/%_defconfig prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(TOPDIR)/configs/$@ \ $< --defconfig=$(TOPDIR)/configs/$@ $(CONFIG_CONFIG_IN) -%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(BR2_EXTERNAL)/configs/%_defconfig outputmakefile +%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(BR2_EXTERNAL)/configs/%_defconfig prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(BR2_EXTERNAL)/configs/$@ \ $< --defconfig=$(BR2_EXTERNAL)/configs/$@ $(CONFIG_CONFIG_IN) -savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile +savedefconfig: $(BUILD_DIR)/buildroot-config/conf prepare-kconfig @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< \ --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
Signature · 1 line
1.9.1
PATCH 4/7 packages: introduce a generated kconfig snippet in the menuconfig
In reply to Yann E. MORINAdd the infrastructure for adding one (and only one) generated kconfig snippet in the "Target packages" sub-menu.
This kconfig snippet will ultimately be generated, to contain the list of services enabled packages will install, so the user may decide to enable or disable each service.
The new file is a PHONY target, sicne we do want to regenrate it on every run (in case the list of services a package defines changes). We can not have it depend on all the .mk files, because we do not have this list.
For now, the kconfig snippet is generated empty, the recipe for filling it in will be introduced in sub-sequent patches.
--- Config.in | 4 ++++ Makefile | 6 +++++- package/Config.in | 2 ++ 3 files changed, 11 insertions(+), 1 deletion(-)
Config.in +4 -0
@@ -18,6 +18,10 @@ config BR2_EXTERNAL string option env="BR2_EXTERNAL" +config BR2_BASE_DIR + string + option env="BASE_DIR" + # Hidden boolean selected by packages in need of Java in order to build # (example: xbmc) config BR2_NEEDS_HOST_JAVA
Makefile +5 -1
@@ -693,7 +693,7 @@ endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y) HOSTCFLAGS = $(CFLAGS_FOR_BUILD) export HOSTCFLAGS -prepare-kconfig: outputmakefile +prepare-kconfig: outputmakefile $(BASE_DIR)/build/.services.in $(BUILD_DIR)/buildroot-config/%onf: mkdir -p $(@D)/lxdialog
@@ -827,6 +827,10 @@ ifeq ($(NEED_WRAPPER),y) $(Q)$(TOPDIR)/support/scripts/mkmakefile $(TOPDIR) $(O) endif +.PHONY: $(BASE_DIR)/build/.services.in +$(BASE_DIR)/build/.services.in: + @touch $(@) + # printvars prints all the variables currently defined in our Makefiles printvars: @$(foreach V, \
package/Config.in +2 -0
@@ -1359,4 +1359,6 @@ if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS endif endmenu +source "$BR2_BASE_DIR/build/.services.in" + endmenu
Signature · 1 line
1.9.1
PATCH 5/7 packages: generate services sub-menu
In reply to Yann E. MORINFor each declared service, generate an entry in the services sub-menu.
This is a no-op for now: nothing is made of the enabled/disabled services; also, no package defines services yes. Both will come in later patches.
--- Makefile | 13 ++++++++++++- package/pkg-generic.mk | 5 +++++ 2 files changed, 17 insertions(+), 1 deletion(-)
Makefile +12 -1
@@ -829,7 +829,18 @@ endif .PHONY: $(BASE_DIR)/build/.services.in $(BASE_DIR)/build/.services.in: - @touch $(@) + @{ \ + printf 'menu "Services to enable"\n\n'; \ + $(foreach pkg,$(sort $(PACKAGES_WITH_SERVICES)),\ + printf 'if BR2_PACKAGE_$(call UPPERCASE,$(pkg))\n\n'; \ + printf 'comment "$(pkg) services"\n\n'; \ + $(foreach srv,$($(call UPPERCASE,$(pkg))_SERVICES), \ + printf 'config BR2_PACKAGE_$(call UPPERCASE,$(pkg))_SRV_$(call UPPERCASE,$(srv))\n'; \ + printf '\tbool "$(srv)"\n\n'; \ + )\ + printf 'endif\n\n';) \ + printf 'endmenu\n'; \ + } >$(@) # printvars prints all the variables currently defined in our Makefiles printvars:
package/pkg-generic.mk +5 -0
@@ -478,6 +478,11 @@ $(2)_POST_INSTALL_IMAGES_HOOKS ?= $(2)_PRE_LEGAL_INFO_HOOKS ?= $(2)_POST_LEGAL_INFO_HOOKS ?= +# Services to enable/disable +ifneq ($$($(2)_SERVICES),) +PACKAGES_WITH_SERVICES += $(1) +endif + # human-friendly targets and target sequencing $(1): $(1)-install
Signature · 1 line
1.9.1
PATCH 6/7 pkg-generic: act on enabled services
In reply to Yann E. MORIN--- package/pkg-generic.mk | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
package/pkg-generic.mk +21 -1
@@ -238,6 +238,7 @@ $(BUILD_DIR)/%/.stamp_target_installed: $($(PKG)_INSTALL_INIT_SYSTEMD)) $(if $(BR2_INIT_SYSV)$(BR2_INIT_BUSYBOX),\ $($(PKG)_INSTALL_INIT_SYSV)) + $($(PKG)_INSTALL_SERVICES) $(foreach hook,$($(PKG)_POST_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep)) $(Q)if test -n "$($(PKG)_CONFIG_SCRIPTS)" ; then \ $(RM) -f $(addprefix $(TARGET_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ; \
@@ -481,7 +482,25 @@ $(2)_POST_LEGAL_INFO_HOOKS ?= # Services to enable/disable ifneq ($$($(2)_SERVICES),) PACKAGES_WITH_SERVICES += $(1) -endif + +ifeq ($(BR2_INIT_SYSV)$(BR2_INIT_BUSYBOX),y) +define $(2)_INSTALL_SERVICES + $(INSTALL) -d -m 0755 $$(TARGET_DIR)/etc/init.d + $(INSTALL) -d -m 0755 $$(TARGET_DIR)/etc/defaults + $$(foreach srv,$$($(2)_SERVICES),\ + $(INSTALL) -D -m 0755 $$(PKGDIR)/S??$$(srv) $$(TARGET_DIR)/etc/init.d/ && \ + printf "ENABLED=%s\n" \ + $$(if $$(BR2_PACKAGE_$(2)_SRV_$$(call UPPERCASE,$$(srv))),YES,NO) \ + >$$(TARGET_DIR)/etc/defaults/$$(srv) && \ + if [ -f $$(PKGDIR)/$$(srv).defaults ]; then \ + cat $$(PKGDIR)/$$(srv).defaults >>$$(TARGET_DIR)/etc/defaults/$$(srv); \ + fi && \ + chmod 644 $$(TARGET_DIR)/etc/defaults/$$(srv) || exit 1$(sep)\ + ) +endef +endif # Sys-V init + +endif # Services # human-friendly targets and target sequencing $(1): $(1)-install
@@ -612,6 +631,7 @@ $(1)-reconfigure: $(1)-clean-for-reconfigure $(1) # define the PKG variable for all targets, containing the # uppercase package variable prefix $$($(2)_TARGET_INSTALL_TARGET): PKG=$(2) +$$($(2)_TARGET_INSTALL_TARGET): PKGDIR=$(pkgdir) $$($(2)_TARGET_INSTALL_STAGING): PKG=$(2) $$($(2)_TARGET_INSTALL_IMAGES): PKG=$(2) $$($(2)_TARGET_INSTALL_HOST): PKG=$(2)
Signature · 1 line
1.9.1
PATCH 7/7 package/busybox: add afake services as example
In reply to Yann E. MORIN--- package/busybox/S98bar | 0 package/busybox/S99foo | 0 package/busybox/bar.defaults | 1 + package/busybox/busybox.mk | 2 ++ 4 files changed, 3 insertions(+) create mode 100644 package/busybox/S98bar create mode 100644 package/busybox/S99foo create mode 100644 package/busybox/bar.defaults
package/busybox/S98bar new file +0 -0
package/busybox/S99foo new file +0 -0
package/busybox/bar.defaults new file +1 -0
@@ -0,0 +1 @@ +FOO=BAR
package/busybox/busybox.mk +2 -0
@@ -4,6 +4,8 @@ # ################################################################################ +BUSYBOX_SERVICES = foo bar + BUSYBOX_VERSION = 1.23.1 BUSYBOX_SITE = http://www.busybox.net/downloads BUSYBOX_SOURCE = busybox-$(BUSYBOX_VERSION).tar.bz2
Signature · 1 line
1.9.1
cover Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)
In reply to Yann E. MORINYann,
This is almost exactly what I was looking for.
Quoted 22 lines · Yann E. MORIN
Hello All!
Following up on Gustavo's proposal [0] on a clean up on our init scripts (and eventually our systemd unit files), here is an *RFC* series that tries to implement Gustavo's idea.
The series is split in four parts:
- patches 1-3 are preparatory work, and not much interesting in the
Grand Scheme of Life;- patches 4-5 introduce a generated kconfig snippet, that contains the list of services for each enabled packages, that the user can enable/disable at will, directly from the menuconfig (for now, the default is that all services are disabled, that can be changed later);
- patch 6 is the guts that installs the service files:
- installs the service's startup script,
- enables/disables the service,
- installs the service's configuration, if it exists;
Quoted 6 lines
- patch 7 is just an example (with empty scripts) of how to declare services in a package.
To be noted:
- the code will need some revamp; this is just meant to be an RFC!
- only sysv init is handled for now
I think systemd could be handled without much effort. Using something similar to your sysv code, all systemd service files would be installed to /usr/lib/systemd/system/ and enabled by symlinking to /etc/systemd/system/multi-user.target.wants/
Quoted 57 lines
- this is by far incomplete even for the sysv case
- the/etc/config/part has been left out for now; it would anyway most probably provided via a rootfs-overlay
- the manual part is missing
- there are typoes all over the place :-/As usual: on your mark, get set, comment! ;-)
[0] http://lists.busybox.net/pipermail/buildroot/2015-March/121086.html
Regards,
Yann E. MORIN.The following changes since commit
a4788aa6157d1496cdd32cb9802710d4e97bc550:btrfs-progs: bump to version 3.19 (2015-03-11 22:38:36 +0100)
are available in the git repository at:
git://git.busybox.net/~ymorin/git/buildrootyem/servicesfor you to fetch changes up to
f2c8684c9a6cfa5cfe8d776ac8ce4693667c329f:[NOT TO BE APPLIED] package/busybox: add afake services as example (2015-03-11 23:08:51 +0100)
----------------------------------------------------------------
Yann E. MORIN (7):
package infra: print the name of the package being parsed
Makefile: always scan packages' .mk files, even with no .config
Makefile: introduce a intermediate rule before the configurators
packages: introduce a generated kconfig snippet in the menuconfig
packages: generate services sub-menu
[INCOMPLETE] pkg-generic: act on enabled services
[NOT TO BE APPLIED] package/busybox: add afake services as exampleConfig.in | 4 +++ Makefile | 67 ++++++++++++++++++++++++++++---------------- package/Config.in | 2 ++ package/busybox/S98bar | 0 package/busybox/S99foo | 0 package/busybox/bar.defaults | 1 + package/busybox/busybox.mk | 2 ++ package/pkg-generic.mk | 28 ++++++++++++++++++ package/pkg-utils.mk | 3 ++ 9 files changed, 83 insertions(+), 24 deletions(-) create mode 100644 package/busybox/S98bar create mode 100644 package/busybox/S99foo create mode 100644 package/busybox/bar.defaults--
.-----------------.--------------------.------------------.--------------------.| 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. |'------------------------------^-------^------------------^--------------------'
cover Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)
In reply to Yann E. MORINDear Yann E. MORIN,
Quoted 3 lines · Yann E. MORIN
Following up on Gustavo's proposal [0] on a clean up on our init scripts (and eventually our systemd unit files), here is an *RFC* series that tries to implement Gustavo's idea.
I am personally not in favor of an approach where kconfig options are used to enable/disable services, because it's a slippery slope. I very much prefer Gustavo's proposal of /etc/{default,config}/ files, that users can override in their rootfs overlays or post-build script.
Why do I have this opinion?
Simply because your proposal is limited to just enabling/disabling services. But then people will want kconfig options to set the TFTP server root directory, to set the lighttpd server options foo or bar, to configure the NTP configuration options, and so on. This is clearly not a direction we want to take I believe as it will simply require more and more and more kconfig options.
Instead, let's have some /etc/default/<service> files, which allow to both define whether <service> is enabled or not, but also allow to set various other service-specific configuration options.
I think Buildroot is a toolbox to generate your system, but you *must* do some additional customization to have a system tailored to your needs. What I believe is great in Buildroot is that is basically just builds the upstream source code, and installs it. It doesn't try to be a distro that imposes its own Web interface, its own organization of the filesystems, etc. We just build and install everything, and provide minimal sane defaults, and let users customize everything else.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
cover Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)
Thomas,
Some comments with regards to how your proposal works with a systemd init.
Quoted 13 lines · Thomas Petazzoni
Dear Yann E. MORIN,
Quoted 3 lines · Yann E. MORIN
Following up on Gustavo's proposal [0] on a clean up on our init scripts (and eventually our systemd unit files), here is an *RFC* series that tries to implement Gustavo's idea.
I am personally not in favor of an approach where kconfig options are used to enable/disable services, because it's a slippery slope. I very much prefer Gustavo's proposal of
/etc/{default,config}/files, that users can override in their rootfs overlays or post-build script.
Quoted 8 lines
Why do I have this opinion?
Simply because your proposal is limited to just enabling/disabling services. But then people will want kconfig options to set the TFTP server root directory, to set the lighttpd server options foo or bar, to configure the NTP configuration options, and so on. This is clearly not a direction we want to take I believe as it will simply require more and more and more kconfig options.
The kconfig option for enabling of systemd service could be generated easily. Each package would simply provide a variable that contains all of the service files to install. This same list could be used to generate a menu for which should be enabled.
Quoted 4 lines
Instead, let's have some /etc/default/<service> files, which allow to both define whether <service> is enabled or not, but also allow to set various other service-specific configuration options.
For what it's worth, that system isn't used / actively discouraged in systemd (not that that systemd should dictate what buildroot does). It does the following:
Installing: service file put in /usr/lib/systemd/system/
Enabling: service file in /usr/lib/systemd/system/ symlinked to /etc/systemd/system/multi-user.target.wants/ (or another target) Overriding defaults / custom configuration: modified copy of service file put in /etc/systemd/system/
This way, all default configuration is in /usr/lib/systemd/ and overrides of the defaults are in /etc/systemd/. The nice thing about this is it is immediately apparent which parts of your system have been modified and which haven't. It also enables a factory reset by simply wiping /etc/.
Quoted 8 lines
I think Buildroot is a toolbox to generate your system, but you *must* do some additional customization to have a system tailored to your needs. What I believe is great in Buildroot is that is basically just builds the upstream source code, and installs it. It doesn't try to be a distro that imposes its own Web interface, its own organization of the filesystems, etc. We just build and install everything, and provide minimal sane defaults, and let users customize everything else.
I agree, that's why I use buildroot. As such, I have a slight preference for not doing any extra configuration beyond building and installing packages in buildroot, including enabling services or configuring sane defaults for services. However, there's definitely a good argument to made that your preference of enabling sane defaults helps beginners starting out with buildroot. And for systemd init, my goal is easy to accomplish, I can simply simply rm -rf /etc/* in a post build script.
Quoted 8 lines
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com