From patchwork Sat Feb 8 20:51:19 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Korsgaard X-Patchwork-Id: 318505 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from silver.osuosl.org (silver.osuosl.org [140.211.166.136]) by ozlabs.org (Postfix) with ESMTP id 4E1D32C00A7 for ; Sun, 9 Feb 2014 07:51:32 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 2C54E32CC1; Sat, 8 Feb 2014 20:51:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFMqVg7tsMrR; Sat, 8 Feb 2014 20:51:27 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 7202731E88; Sat, 8 Feb 2014 20:51:27 +0000 (UTC) X-Original-To: buildroot@lists.busybox.net Delivered-To: buildroot@osuosl.org Received: from whitealder.osuosl.org (whitealder.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id E16261BF989 for ; Sat, 8 Feb 2014 20:51:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id DF56D8BF3E for ; Sat, 8 Feb 2014 20:51:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKP8E0qyA5b4 for ; Sat, 8 Feb 2014 20:51:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by whitealder.osuosl.org (Postfix) with ESMTPS id 163158B9CB for ; Sat, 8 Feb 2014 20:51:24 +0000 (UTC) Received: by mail-ea0-f172.google.com with SMTP id l9so1865582eaj.17 for ; Sat, 08 Feb 2014 12:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=mt0B9mHlgbL5Q9EQaXeKpqe11ikvWIOm6HW3CUy/ezc=; b=owWzrtmaZY8xy0pfYXKH+kpuPLWaHT9oIvvrEDdodDK/EKweCoZS+cLFj1KYoU7HTI kpcbVOMyZbP9Br/baJflz8YWjLOWKvlyzZW5DJXH//I+jyvffoICqxNfIZvQtiwfc2OH 8pWvbmNzkqKXnFheRTMYE5H14iQlMEsZKtmiMreox8v7ETohFEIe7+VzHklPL5evyAU3 82ytv3ABy+BffwUoEdejLCcbCdwqeTPwSGebFUuxrJ2zwwLH5qsvmXYYXWipLbk4yuDL Cz8eSau+AD/oi0gq1Ss01ta7eeoexEKYY+hbjvKsKZLVHh4BbRBAea/piyGnLmsP9bbr nJ4w== X-Received: by 10.15.67.197 with SMTP id u45mr25117460eex.24.1391892683565; Sat, 08 Feb 2014 12:51:23 -0800 (PST) Received: from dell.be.48ers.dk ([2001:6f8:1434:0:6267:20ff:fe4e:21b6]) by mx.google.com with ESMTPSA id k6sm33187883eep.17.2014.02.08.12.51.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 08 Feb 2014 12:51:22 -0800 (PST) Received: from peko by dell.be.48ers.dk with local (Exim 4.80) (envelope-from ) id 1WCErv-0005cK-U0; Sat, 08 Feb 2014 21:51:19 +0100 From: Peter Korsgaard To: Thomas De Schampheleire References: <769563a34e142e85ec4c.1391761259@argentina> <87wqh6640h.fsf@dell.be.48ers.dk> <87ob2i63cg.fsf@dell.be.48ers.dk> Date: Sat, 08 Feb 2014 21:51:19 +0100 In-Reply-To: (Thomas De Schampheleire's message of "Fri, 7 Feb 2014 22:16:13 +0100") Message-ID: <87k3d55nw8.fsf@dell.be.48ers.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Cc: buildroot , Andreas Koop , Peter Korsgaard Subject: Re: [Buildroot] [PATCH] linux: don't automatically set uevent_helper with mdev /dev management X-BeenThere: buildroot@busybox.net X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: buildroot-bounces@busybox.net Sender: buildroot-bounces@busybox.net >>>>> "Thomas" == Thomas De Schampheleire writes: Hi, >> No, mdev -s only scans /sys for devices and create the corresponding >> device nodes (already done by devtmpfs) and execute whatever commands >> you have defined, it afaik doesn't handle module load or firmware requests. > When you say 'module load', the only relevant consequence of that is > the creation of nodes in /sys that may need corresponding entries in > /dev right? So this is covered by the S10mdev script, as far as I see. > What else would happen in 'module load' that mdev does not cover? I mean module load as in automatic loading of kernel modules modprobe. The kernel generates hotplug events with the needed modalias that mdev can pass to modprobe, but our mdev.conf is not setup to do that. Here's a blog post about it: https://frankpzh.wordpress.com/2011/04/16/kmod-udev-and-modprobe/ > However, the kernel configuration says: "This should not be used > today, because usual systems create many events at bootup or device > discovery in a very short time frame. One forked process per event can > create so many processes that it creates a high system load, or on > smaller systems it is known to create out-of-memory situations during > bootup." Yes, the "modern" way to send these events (E.G. what udev is using) is afaik through netlink instead of forking a process for each, but if you want to handle these events through mdev then there's not really any way around it. > So then I wonder, how is it supposed to work for module load and > firmware loading if you can't use this option. Or put another way: are > you sure we need to set the uevent_helper_path for that? If you want to be notified of hotplug events (and don't use netlink), then you have to set it. Out of interest I did a quick test with qemu_arm_versatile_defconfig and the following patch: And I see the kernel triggers 357 hotplug events before we get here. Looking at the pid number after bootup and login that also seems to match (428 with CONFIG_UEVENT_HELPER_PATH="/sbin/mdev" and 73 when set to the empty string), but I don't see any significant boot speed difference here. So, I'm not saying I don't believe you or that it perhaps wouldn't be better to handle the initial hotplug events with mdev, just that it less "correct" - But mdev is afaik inherently racy, so perhaps not doing it would be the "least bad" approach (and gives us same behaviour if kernel isn't built by buildroot). diff -u package/busybox/S10mdev output/target/etc/init.d/S10mdev --- package/busybox/S10mdev 2013-10-24 09:55:30.270408593 +0200 +++ output/target/etc/init.d/S10mdev 2014-02-08 21:26:48.450713447 +0100 @@ -7,6 +7,8 @@ start) echo "Starting mdev..." echo /sbin/mdev >/proc/sys/kernel/hotplug + echo -n "seqnum: " + cat /sys/kernel/uevent_seqnum /sbin/mdev -s ;; stop)