[10/10] package/mdevd: bump version to 0.1.1.0

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

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