[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

Register mdev as hotplug helper for many goodies and expected behaviour
(like automatic firmware loading).

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/busybox/S10mdev | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/busybox/S10mdev b/package/busybox/S10mdev
index c06aa20..c41f166 100644
--- a/package/busybox/S10mdev
+++ b/package/busybox/S10mdev
@@ -6,6 +6,7 @@
 case "$1" in
   start)
 	echo "Starting mdev..."
+	echo /sbin/mdev 2>/dev/null >/proc/sys/kernel/hotplug
 	/sbin/mdev -s
 	;;
   stop)
-- 
1.8.1.5

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas De Schampheleire]

Hi Gustavo,

On Thu, Jul 11, 2013 at 10:30 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> Register mdev as hotplug helper for many goodies and expected behaviour
> (like automatic firmware loading).
>
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/busybox/S10mdev | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/package/busybox/S10mdev b/package/busybox/S10mdev
> index c06aa20..c41f166 100644
> --- a/package/busybox/S10mdev
> +++ b/package/busybox/S10mdev
> @@ -6,6 +6,7 @@
>  case "$1" in
>    start)
>         echo "Starting mdev..."
> +       echo /sbin/mdev 2>/dev/null >/proc/sys/kernel/hotplug
>         /sbin/mdev -s
>         ;;
>    stop)

In linux/linux.mk, there mdev is already set as hotplug helper in the
kernel configuration.
How does this change relate to it? At first sight, it seems unnecessary.

I did notice that setting mdev as hotplug helper in the kernel
configuration, can seriously impact boot performance. On a board with
a not so fast single core processor (around 500MHz) boot time until
userspace became about 10 seconds coming from 2s. We solved this by
setting no helper in the kernel configuration (and telling buildroot
to use just devtmpfs instead of mdev), and manually copying S10mdev to
the rootfs. Then, mdev is run once during userspace init.
This doesn't give automatic firmware loading, but that would be solved
by your above patch, I think.

Did anyone else notice such slowdown behavior?

Best regards,
Thomas

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/12/2013 04:01 AM, Thomas De Schampheleire wrote:
> In linux/linux.mk, there mdev is already set as hotplug helper in the
> kernel configuration.
> How does this change relate to it? At first sight, it seems unnecessary.
> 
> I did notice that setting mdev as hotplug helper in the kernel
> configuration, can seriously impact boot performance. On a board with
> a not so fast single core processor (around 500MHz) boot time until
> userspace became about 10 seconds coming from 2s. We solved this by
> setting no helper in the kernel configuration (and telling buildroot
> to use just devtmpfs instead of mdev), and manually copying S10mdev to
> the rootfs. Then, mdev is run once during userspace init.
> This doesn't give automatic firmware loading, but that would be solved
> by your above patch, I think.
> 
> Did anyone else notice such slowdown behavior?

I actually came up with this patch because a user on a pandaboard had
issues getting the wifi up (wl127x, needs firmware).
At first he was running a static device tree configuration which
explained the problem.
He then switched to mdev and things didn't work, and switching to udev
did make it work.
So i looked at S10mdev and saw that the hotplug helper wasn't registered.
It's likely that he didn't make clean between switching to mdev and the
kernel hence didn't get reconfigured/rebuilt and that was the problem.
However as you say, if the kernel has pre-registered the hotplug helper
in the configuration all the hotplug events at boot time are probably
getting called (all the bus interfaces and whatnot).
I tend to use my own initscripts tree since it's quite tweaked regarding
the bare default (i basically nuke all of buildroots initscripts and
replace them with my own), and on an arm920t (slow really, 180 mhz) i
have no major delay when using this method.
The only "drawback" would be missing usb devices if they're already
plugged in and the usb controller driver isn't a module - but really
that's coldplug-world.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas De Schampheleire]

Hi,

On Fri, Jul 12, 2013 at 12:27 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 07/12/2013 04:01 AM, Thomas De Schampheleire wrote:
>> In linux/linux.mk, there mdev is already set as hotplug helper in the
>> kernel configuration.
>> How does this change relate to it? At first sight, it seems unnecessary.
>>
>> I did notice that setting mdev as hotplug helper in the kernel
>> configuration, can seriously impact boot performance. On a board with
>> a not so fast single core processor (around 500MHz) boot time until
>> userspace became about 10 seconds coming from 2s. We solved this by
>> setting no helper in the kernel configuration (and telling buildroot
>> to use just devtmpfs instead of mdev), and manually copying S10mdev to
>> the rootfs. Then, mdev is run once during userspace init.
>> This doesn't give automatic firmware loading, but that would be solved
>> by your above patch, I think.
>>
>> Did anyone else notice such slowdown behavior?
>
> I actually came up with this patch because a user on a pandaboard had
> issues getting the wifi up (wl127x, needs firmware).
> At first he was running a static device tree configuration which
> explained the problem.
> He then switched to mdev and things didn't work, and switching to udev
> did make it work.
> So i looked at S10mdev and saw that the hotplug helper wasn't registered.
> It's likely that he didn't make clean between switching to mdev and the
> kernel hence didn't get reconfigured/rebuilt and that was the problem.
> However as you say, if the kernel has pre-registered the hotplug helper
> in the configuration all the hotplug events at boot time are probably
> getting called (all the bus interfaces and whatnot).
> I tend to use my own initscripts tree since it's quite tweaked regarding
> the bare default (i basically nuke all of buildroots initscripts and
> replace them with my own), and on an arm920t (slow really, 180 mhz) i
> have no major delay when using this method.
> The only "drawback" would be missing usb devices if they're already
> plugged in and the usb controller driver isn't a module - but really
> that's coldplug-world.
> Regards.
>

So what do we do with this patch?
I ask it because it's still marked as 'New' in patchwork:
http://patchwork.ozlabs.org/patch/258619/
If we agree that it shouldn't be needed, I suggest to mark it as such.
If someone can come up with a proven failure scenario, we can still reopen it.

What do you think?

Thanks,
Thomas

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote:

> So what do we do with this patch?
> I ask it because it's still marked as 'New' in patchwork:
> http://patchwork.ozlabs.org/patch/258619/
> If we agree that it shouldn't be needed, I suggest to mark it as such.
> If someone can come up with a proven failure scenario, we can still reopen it.
> 
> What do you think?

Proven failure: not building a kernel with buildroot.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas De Schampheleire]

On Sun, Jul 28, 2013 at 1:28 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote:
>
>> So what do we do with this patch?
>> I ask it because it's still marked as 'New' in patchwork:
>> http://patchwork.ozlabs.org/patch/258619/
>> If we agree that it shouldn't be needed, I suggest to mark it as such.
>> If someone can come up with a proven failure scenario, we can still reopen it.
>>
>> What do you think?
>
> Proven failure: not building a kernel with buildroot.

Agreed. So in this case, the patch can be helpful.

One question then about it: what is the purpose of the 2>/dev/null ?
How would echo fail?

Thanks,
Thomas

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 08:56 AM, Thomas De Schampheleire wrote:

> Agreed. So in this case, the patch can be helpful.
> 
> One question then about it: what is the purpose of the 2>/dev/null ?
> How would echo fail?

No hotplug support in the kernel.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas De Schampheleire]

On Sun, Jul 28, 2013 at 1:57 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 07/28/2013 08:56 AM, Thomas De Schampheleire wrote:
>
>> Agreed. So in this case, the patch can be helpful.
>>
>> One question then about it: what is the purpose of the 2>/dev/null ?
>> How would echo fail?
>
> No hotplug support in the kernel.

Alright, you win ;-)

Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 09:09 AM, Thomas De Schampheleire wrote:
> Alright, you win ;-)
> 
> Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Actually users who don't do the kernel in buildroot win, i usually do.
And even if i didn't i use my own set of customs scripts :)
Thanks.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 28 Jul 2013 08:28:55 -0300, Gustavo Zacarias wrote:
> On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote:
> 
> > So what do we do with this patch?
> > I ask it because it's still marked as 'New' in patchwork:
> > http://patchwork.ozlabs.org/patch/258619/
> > If we agree that it shouldn't be needed, I suggest to mark it as such.
> > If someone can come up with a proven failure scenario, we can still reopen it.
> > 
> > What do you think?
> 
> Proven failure: not building a kernel with buildroot.

Not really an argument: if you select 'devtmpfs' as the /dev management
method and you build your kernel outside of Buildroot, you have to
enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't
work. I don't see what it shouldn't be the same for the hotplug helper
selection: if you're building the kernel with Buildroot, then things are
taken care of automatically, otherwise you're on your own.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 10:14 AM, Thomas Petazzoni wrote:

>> Proven failure: not building a kernel with buildroot.
> 
> Not really an argument: if you select 'devtmpfs' as the /dev management
> method and you build your kernel outside of Buildroot, you have to
> enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't
> work. I don't see what it shouldn't be the same for the hotplug helper
> selection: if you're building the kernel with Buildroot, then things are
> taken care of automatically, otherwise you're on your own.

Then we should just ditch the device managment options if the user isn't
building a kernel?
Double-edged knife there :)
For mdev that can be solved, at worst it'll be an (almost) no-op,
devtmpfs is another story.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 28 Jul 2013 10:38:06 -0300, Gustavo Zacarias wrote:

> >> Proven failure: not building a kernel with buildroot.
> > 
> > Not really an argument: if you select 'devtmpfs' as the /dev management
> > method and you build your kernel outside of Buildroot, you have to
> > enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't
> > work. I don't see what it shouldn't be the same for the hotplug helper
> > selection: if you're building the kernel with Buildroot, then things are
> > taken care of automatically, otherwise you're on your own.
> 
> Then we should just ditch the device managment options if the user isn't
> building a kernel?

No because it also controls whether the device_table_dev.txt is use
to create static devices or not. It also controls whether the udev
package is built, etc. So clearly the device management options aren't
just controlling the kernel configuration, but a lot of other things as
well.

> For mdev that can be solved, at worst it'll be an (almost) no-op,
> devtmpfs is another story.

That's true.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 10:51 AM, Thomas Petazzoni wrote:

>> For mdev that can be solved, at worst it'll be an (almost) no-op,
>> devtmpfs is another story.
> 
> That's true.

It basically boils down to helping people or not on alternate scenarios.
Some random guy in #pandaboard was having issues loading firmware on a
prebuilt kernel (which sometimes happens to be a sore PITA to build a
working kernel with some vendors/for some people, no point in arguing
that no matter how much we wish everything were upstreamed/vanilla) for
WiFi support and (obviously) mdev wasn't working.
Solution was get your kernel source/config right, or fix the script.
The script was a quick way out without bad side effects.
On a personal level i don't care about the patch, it was just a quick
and painless way of fixing a common problem.
Regards.

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 28 Jul 2013 11:01:29 -0300, Gustavo Zacarias wrote:

> It basically boils down to helping people or not on alternate scenarios.
> Some random guy in #pandaboard was having issues loading firmware on a
> prebuilt kernel (which sometimes happens to be a sore PITA to build a
> working kernel with some vendors/for some people, no point in arguing
> that no matter how much we wish everything were upstreamed/vanilla) for
> WiFi support and (obviously) mdev wasn't working.
> Solution was get your kernel source/config right, or fix the script.
> The script was a quick way out without bad side effects.
> On a personal level i don't care about the patch, it was just a quick
> and painless way of fixing a common problem.

Right. But then maybe the 2>/dev/null should be removed, so that if the
sysctl file to set the hotplug helper doesn't exist, the user sees that
something is wrong?

(That said, I think CONFIG_HOTPLUG has become mandatory in recent
kernels, so it shouldn't be a big problem.)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] busybox: register mdev as hotplug helper

[Gustavo Zacarias]

On 07/28/2013 11:03 AM, Thomas Petazzoni wrote:

> Right. But then maybe the 2>/dev/null should be removed, so that if the
> sysctl file to set the hotplug helper doesn't exist, the user sees that
> something is wrong?
> 
> (That said, I think CONFIG_HOTPLUG has become mandatory in recent
> kernels, so it shouldn't be a big problem.)

Yes, it's been for a while it seems, not completely cleaned up from the
kernel though (it's still mentioned in Documentation, several defconfigs
and a couple of source files).
Ok, i'll resend without the stderr pipe.
Regards.