[10/10] package/mdevd: bump version to 0.1.1.0
diff mbox series

Message ID 20190929171017.26831-11-eric.le.bihan.dev@free.fr
State New
Headers show
Series
  • Bump skarnet packages to 2019.09 release
Related show

Commit Message

Eric Le Bihan Sept. 29, 2019, 5:10 p.m. UTC
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

Comments

Thomas Petazzoni Sept. 30, 2019, 8:57 p.m. UTC | #1
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
Peter Korsgaard Sept. 30, 2019, 9:25 p.m. UTC | #2
>>>>> "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?
Eric Le Bihan Sept. 30, 2019, 11:14 p.m. UTC | #3
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
Thomas Petazzoni Oct. 1, 2019, 6:50 a.m. UTC | #4
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
Arnout Vandecappelle Oct. 1, 2019, 8:35 a.m. UTC | #5
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
Yann E. MORIN Oct. 2, 2019, 7:25 p.m. UTC | #6
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.
Eric Le Bihan Oct. 6, 2019, 3:33 p.m. UTC | #7
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
Eric Le Bihan Oct. 6, 2019, 3:43 p.m. UTC | #8
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

Patch
diff mbox series

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