Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] busybox: register mdev as hotplug helper
Date: Fri, 12 Jul 2013 07:27:43 -0300	[thread overview]
Message-ID: <51DFDA1F.60904@zacarias.com.ar> (raw)
In-Reply-To: <CAAXf6LVSOCLS54uAwJHH6DwenrexRY=17v_PoOe_KTnmWWTvWg@mail.gmail.com>

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.

  reply	other threads:[~2013-07-12 10:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 20:30 [Buildroot] [PATCH] busybox: register mdev as hotplug helper Gustavo Zacarias
2013-07-12  7:01 ` Thomas De Schampheleire
2013-07-12 10:27   ` Gustavo Zacarias [this message]
2013-07-28  8:33     ` Thomas De Schampheleire
2013-07-28 11:28       ` Gustavo Zacarias
2013-07-28 11:56         ` Thomas De Schampheleire
2013-07-28 11:57           ` Gustavo Zacarias
2013-07-28 12:09             ` Thomas De Schampheleire
2013-07-28 12:12               ` Gustavo Zacarias
2013-07-28 13:14         ` Thomas Petazzoni
2013-07-28 13:38           ` Gustavo Zacarias
2013-07-28 13:51             ` Thomas Petazzoni
2013-07-28 14:01               ` Gustavo Zacarias
2013-07-28 14:03                 ` Thomas Petazzoni
2013-07-28 14:12                   ` Gustavo Zacarias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51DFDA1F.60904@zacarias.com.ar \
    --to=gustavo@zacarias.com.ar \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox