Message ID | 20190929171017.26831-11-eric.le.bihan.dev@free.fr |
---|---|
State | Accepted |
Headers | show |
Series | Bump skarnet packages to 2019.09 release | expand |
On Sun, 29 Sep 2019 19:10:17 +0200 Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > This new package provides mdevd, a small daemon managing kernel hotplug > events similar to udevd. > > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> We have a choice between static /dev, devtmpfs, devtmpfs + Busybox mdev, devtmpfs + eudev, should we add a choice of devtmpfs + mdevd ? What happens if we have both Busybox mdev *and* mdevd in the same configuration ? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: > On Sun, 29 Sep 2019 19:10:17 +0200 > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: >> This new package provides mdevd, a small daemon managing kernel hotplug >> events similar to udevd. >> >> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> > We have a choice between static /dev, devtmpfs, devtmpfs + Busybox > mdev, devtmpfs + eudev, should we add a choice of devtmpfs + mdevd ? > What happens if we have both Busybox mdev *and* mdevd in the same > configuration ? What is the advantage of mdevd over mdev now that we use the daemon mode of mdev?
Hi! On 2019-09-30 23:25, Peter Korsgaard wrote: > >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: > > > On Sun, 29 Sep 2019 19:10:17 +0200 > > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > > >> This new package provides mdevd, a small daemon managing kernel hotplug > >> events similar to udevd. > >> > >> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> > > > We have a choice between static /dev, devtmpfs, devtmpfs + Busybox > > mdev, devtmpfs + eudev, should we add a choice of devtmpfs + mdevd ? > > > What happens if we have both Busybox mdev *and* mdevd in the same > > configuration ? > > What is the advantage of mdevd over mdev now that we use the daemon mode > of mdev? I did not know about the daemon mode of mdev, but mdevd was created to overcome the mdev forking issue [1] and predates the daemon option [2]. So in the end, they provide the same features, with mdevd also complying with s6 notification mechanism [3], making it more tightly coupled with this init system. Given that there is no option in menuconfig to use a s6-based init system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. Users should select the mdevd package when implementing their own custom s6-based init. [1] https://skarnet.org/software/mdevd/mdevd.html [2] https://git.skarnet.org/cgi-bin/cgit.cgi/mdevd/tag/?h=v0.0.1.0 [3] https://skarnet.org/software/s6/notifywhenup.html [4] http://buildroot-busybox.2317881.n4.nabble.com/RFC-0-3-init-Add-s6-as-init-system-tp213980p216232.html Regards, -- ELB
On Tue, 1 Oct 2019 01:14:41 +0200 Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > I did not know about the daemon mode of mdev, but mdevd was created to > overcome the mdev forking issue [1] and predates the daemon option [2]. > > So in the end, they provide the same features, with mdevd also complying > with s6 notification mechanism [3], making it more tightly coupled with > this init system. > > Given that there is no option in menuconfig to use a s6-based init > system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. But then there is nothing that prevents them from enabling devtmpfs+eudev as the /dev management system, and separately enable mdevd. That wouldn't work very well. On the other hand, if a user enables both openssh and dropbear, in their default configuration, both will try to listen on TCP port 22, which won't work as well. So perhaps we can live with having mdevd as a standalone package, with no specific handling in the /dev management choice. I'm just a bit worried about users who will enable this mdevd package, while they are looking for Busybox mdev. Thomas
On 01/10/2019 08:50, Thomas Petazzoni wrote: > On Tue, 1 Oct 2019 01:14:41 +0200 > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > >> I did not know about the daemon mode of mdev, but mdevd was created to >> overcome the mdev forking issue [1] and predates the daemon option [2]. >> >> So in the end, they provide the same features, with mdevd also complying >> with s6 notification mechanism [3], making it more tightly coupled with >> this init system. >> >> Given that there is no option in menuconfig to use a s6-based init >> system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. > > But then there is nothing that prevents them from enabling > devtmpfs+eudev as the /dev management system, and separately enable > mdevd. That wouldn't work very well. > > On the other hand, if a user enables both openssh and dropbear, in > their default configuration, both will try to listen on TCP port 22, > which won't work as well. So perhaps we can live with having mdevd as a > standalone package, with no specific handling in the /dev management > choice. I'm just a bit worried about users who will enable this mdevd > package, while they are looking for Busybox mdev. AFAIU, the s6 tools are really an ecosystem. So I think it would make sense to move all of them into a "s6 system management" menu under System tools. That should make it sufficiently clear that this is not related to busybox mdev. Regards, Arnout
Arnout, All, On 2019-10-01 10:35 +0200, Arnout Vandecappelle spake thusly: > On 01/10/2019 08:50, Thomas Petazzoni wrote: > > On Tue, 1 Oct 2019 01:14:41 +0200 > > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > > > >> I did not know about the daemon mode of mdev, but mdevd was created to > >> overcome the mdev forking issue [1] and predates the daemon option [2]. > >> > >> So in the end, they provide the same features, with mdevd also complying > >> with s6 notification mechanism [3], making it more tightly coupled with > >> this init system. > >> > >> Given that there is no option in menuconfig to use a s6-based init > >> system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. > > > > But then there is nothing that prevents them from enabling > > devtmpfs+eudev as the /dev management system, and separately enable > > mdevd. That wouldn't work very well. > > > > On the other hand, if a user enables both openssh and dropbear, in > > their default configuration, both will try to listen on TCP port 22, > > which won't work as well. So perhaps we can live with having mdevd as a > > standalone package, with no specific handling in the /dev management > > choice. I'm just a bit worried about users who will enable this mdevd > > package, while they are looking for Busybox mdev. > > AFAIU, the s6 tools are really an ecosystem. So I think it would make sense to > move all of them into a "s6 system management" menu under System tools. That > should make it sufficiently clear that this is not related to busybox mdev. Doesn't s6 also come with an init system of its own, too? In which case, it would be more akin to the systemd situation. Regards, Yann E. MORIN.
On 2019-10-01 10:35, Arnout Vandecappelle wrote: > > > On 01/10/2019 08:50, Thomas Petazzoni wrote: > > On Tue, 1 Oct 2019 01:14:41 +0200 > > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > > > >> I did not know about the daemon mode of mdev, but mdevd was created to > >> overcome the mdev forking issue [1] and predates the daemon option [2]. > >> > >> So in the end, they provide the same features, with mdevd also complying > >> with s6 notification mechanism [3], making it more tightly coupled with > >> this init system. > >> > >> Given that there is no option in menuconfig to use a s6-based init > >> system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. > > > > But then there is nothing that prevents them from enabling > > devtmpfs+eudev as the /dev management system, and separately enable > > mdevd. That wouldn't work very well. > > > > On the other hand, if a user enables both openssh and dropbear, in > > their default configuration, both will try to listen on TCP port 22, > > which won't work as well. So perhaps we can live with having mdevd as a > > standalone package, with no specific handling in the /dev management > > choice. I'm just a bit worried about users who will enable this mdevd > > package, while they are looking for Busybox mdev. > > AFAIU, the s6 tools are really an ecosystem. So I think it would make sense to > move all of them into a "s6 system management" menu under System tools. That > should make it sufficiently clear that this is not related to busybox mdev. Currently, the following packages are listed individually in the "System tools" section: s6, s6-linux-init, s6-linux-utils, s6-portable-utils, s6-rc. The packages s6, s6-linux-init, s6-rc are the ones to use for building a real s6-based init system. s6-linux-utils and s6-portable-utils provide alternatives to busybox/coreutils and a few niceties (e.g. s6-fillurandompool). They can be used with any init systems. It looks sensible to move them to a submenu named "s6 system management" and add mdevd to it to avoid confusion. But IMHO other skarnet packages like the execline scripting language should be kept out of it as it not s6-related, though used most of the time when building a s6-based init system. Regards, -- ELB
On 2019-10-02 21:25, Yann E. MORIN wrote: > Arnout, All, > > On 2019-10-01 10:35 +0200, Arnout Vandecappelle spake thusly: > > On 01/10/2019 08:50, Thomas Petazzoni wrote: > > > On Tue, 1 Oct 2019 01:14:41 +0200 > > > Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > > > > > >> I did not know about the daemon mode of mdev, but mdevd was created to > > >> overcome the mdev forking issue [1] and predates the daemon option [2]. > > >> > > >> So in the end, they provide the same features, with mdevd also complying > > >> with s6 notification mechanism [3], making it more tightly coupled with > > >> this init system. > > >> > > >> Given that there is no option in menuconfig to use a s6-based init > > >> system [4], I see no reason to add a "devtmpfs+mdevd" option ATM. > > > > > > But then there is nothing that prevents them from enabling > > > devtmpfs+eudev as the /dev management system, and separately enable > > > mdevd. That wouldn't work very well. > > > > > > On the other hand, if a user enables both openssh and dropbear, in > > > their default configuration, both will try to listen on TCP port 22, > > > which won't work as well. So perhaps we can live with having mdevd as a > > > standalone package, with no specific handling in the /dev management > > > choice. I'm just a bit worried about users who will enable this mdevd > > > package, while they are looking for Busybox mdev. > > > > AFAIU, the s6 tools are really an ecosystem. So I think it would make sense to > > move all of them into a "s6 system management" menu under System tools. That > > should make it sufficiently clear that this is not related to busybox mdev. > > Doesn't s6 also come with an init system of its own, too? In which case, > it would be more akin to the systemd situation. In a way, the s6 ecosystem is more a kit to build an init system than a full init system stack like systemd. The author emphasizes that it provides a mechanism and not policies. For example, some users mix the services supervision part (s6) and OpenRC [1]. The mdevd program can be used without s6, unlike udev which is now part of systemd (this situation lead to the creation of eudev). [1] https://github.com/OpenRC/openrc/blob/master/s6-guide.md Regards, -- ELB
On 29/09/2019 19:10, Eric Le Bihan wrote: > This new package provides mdevd, a small daemon managing kernel hotplug > events similar to udevd. > > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Applied to master, thanks. Regards, Arnout
diff --git a/DEVELOPERS b/DEVELOPERS index 8cbf55fd10..ef38004b2e 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -683,6 +683,7 @@ F: package/eudev/ F: package/execline/ F: package/hicolor-icon-theme/ F: package/jemalloc/ +F: package/mdevd/ F: package/meson/ F: package/ninja/ F: package/pkg-meson.mk diff --git a/package/Config.in b/package/Config.in index 713ef79edb..c3417c9839 100644 --- a/package/Config.in +++ b/package/Config.in @@ -478,6 +478,7 @@ endmenu source "package/lvm2/Config.in" source "package/mali-t76x/Config.in" source "package/mdadm/Config.in" + source "package/mdevd/Config.in" source "package/memtest86/Config.in" source "package/memtester/Config.in" source "package/memtool/Config.in" diff --git a/package/mdevd/Config.in b/package/mdevd/Config.in new file mode 100644 index 0000000000..046094039c --- /dev/null +++ b/package/mdevd/Config.in @@ -0,0 +1,9 @@ +config BR2_PACKAGE_MDEVD + bool "mdevd" + depends on BR2_USE_MMU # skalibs + select BR2_PACKAGE_SKALIBS + help + mdevd is a small daemon managing kernel hotplug events, + similarly to udevd. + + http://skarnet.org/software/mdevd/ diff --git a/package/mdevd/mdevd.hash b/package/mdevd/mdevd.hash new file mode 100644 index 0000000000..55b0af4496 --- /dev/null +++ b/package/mdevd/mdevd.hash @@ -0,0 +1,3 @@ +# Locally generated +sha256 302819dceb2400f299ef8f04828a4fe9156d7334e41ce34d61db37fbc2aa7e8f mdevd-0.1.1.0.tar.gz +sha256 e5319cb67bd1d896f3b2fa1136034b1b155a6e278ab1c2578a394f758f0034c1 COPYING diff --git a/package/mdevd/mdevd.mk b/package/mdevd/mdevd.mk new file mode 100644 index 0000000000..603a35731c --- /dev/null +++ b/package/mdevd/mdevd.mk @@ -0,0 +1,39 @@ +################################################################################ +# +# mdevd +# +################################################################################ + +MDEVD_VERSION = 0.1.1.0 +MDEVD_SITE = http://skarnet.org/software/mdevd +MDEVD_LICENSE = ISC +MDEVD_LICENSE_FILES = COPYING +MDEVD_INSTALL_STAGING = YES +MDEVD_DEPENDENCIES = skalibs + +MDEVD_CONF_OPTS = \ + --prefix=/usr \ + --with-sysdeps=$(STAGING_DIR)/usr/lib/skalibs/sysdeps \ + --with-include=$(STAGING_DIR)/usr/include \ + --with-dynlib=$(STAGING_DIR)/usr/lib \ + --with-lib=$(STAGING_DIR)/usr/lib/skalibs \ + $(if $(BR2_STATIC_LIBS),,--disable-allstatic) \ + $(SHARED_STATIC_LIBS_OPTS) + +define MDEVD_CONFIGURE_CMDS + (cd $(@D); $(TARGET_CONFIGURE_OPTS) ./configure $(MDEVD_CONF_OPTS)) +endef + +define MDEVD_BUILD_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) +endef + +define MDEVD_INSTALL_TARGET_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) install +endef + +define MDEVD_INSTALL_STAGING_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) install +endef + +$(eval $(generic-package))
This new package provides mdevd, a small daemon managing kernel hotplug events similar to udevd. Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> --- DEVELOPERS | 1 + package/Config.in | 1 + package/mdevd/Config.in | 9 +++++++++ package/mdevd/mdevd.hash | 3 +++ package/mdevd/mdevd.mk | 39 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 53 insertions(+) create mode 100644 package/mdevd/Config.in create mode 100644 package/mdevd/mdevd.hash create mode 100644 package/mdevd/mdevd.mk