Return-path: Received: from he.sipsolutions.net ([78.46.109.217]:39362 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754490Ab2GXOQc (ORCPT ); Tue, 24 Jul 2012 10:16:32 -0400 Message-ID: <1343139390.4415.31.camel@jlt3.sipsolutions.net> (sfid-20120724_161642_535858_48845418) Subject: Re: calling request_firmware() from module init will not work with recent/future udev versions From: Johannes Berg To: Kay Sievers Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org, Tom Gundersen , Andy Whitcroft Date: Tue, 24 Jul 2012 16:16:30 +0200 In-Reply-To: (sfid-20120719_124643_767103_5E67814F) References: <1326621743.3448.1.camel@jlt3.sipsolutions.net> <1326704259.3510.3.camel@jlt3.sipsolutions.net> <1326716209.3510.7.camel@jlt3.sipsolutions.net> (sfid-20120719_124643_767103_5E67814F) Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, 2012-07-19 at 12:46 +0200, Kay Sievers wrote: > >> > What I'm was asking then is this: Can udev know that it is running from > >> > initramfs (presumably that can't be too hard) and simply not reply to > >> > async requests it doesn't have firmware for? Then once the real root is > >> > mounted it could satisfy (or not) firmware requests from the real root. > >> > >> We can surely change it to not cancel the firmware request. > >> > >> Either by making it aware that we run from initramfs, or by never > >> cancelling any firmware request and just leave it hanging around for > >> forever? > > Never say 6 months is a long time to reply. :) Hehe :-) > Fedora uses systemd in the initramfs now, which made it trivial to > implement this, and to leave the firmware requests hanging around > until we reach in the real rootfs and know if the firmware file is > available: > http://cgit.freedesktop.org/systemd/systemd/commit/?id=39177382a4f92a834b568d6ae5d750eb2a5a86f9 > > The logic to tell udev that it runs in the initramfs could easily be > implemented by other initramfs tools than dracut, but they usually do > not really follow what we do here, so this might for now only work on > recent systems using dracut. Ok, too bad there wasn't a generic way, but at least there's a way now :-) Anyway, I think this is a good thing. johannes