busybox: register mdev as hotplug helper

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

Signed-off-by Gustavo Zacarias <[email protected]>

---
 package/busybox/S10mdev | 1 +
 1 file changed, 1 insertion(+)

package/busybox/S10mdev +0 -0

index c06aa20..c41f166 100644

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?

Quoted 14 lines · Thomas De Schampheleire

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.

Quoted 1 line

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?

Quoted 7 lines · Thomas De Schampheleire

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?

Quoted 4 lines · Thomas De Schampheleire

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 <[email protected]>

Quoted 7 lines · Thomas De Schampheleire

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.

Quoted 1 line

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.

Quoted 8 lines

Quoted 1 line

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?

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

Quoted 2 lines

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.

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