Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754497AbcJEBtE (ORCPT ); Tue, 4 Oct 2016 21:49:04 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:40725 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754436AbcJEBtC (ORCPT ); Tue, 4 Oct 2016 21:49:02 -0400 Date: Tue, 4 Oct 2016 18:48:49 -0700 From: Josh Triplett To: Linus Torvalds Cc: "Luis R. Rodriguez" , Dmitry Torokhov , "Herbert, Marc" , "open list:DOCUMENTATION" , Jacek Anaszewski , David Woodhouse , Christian Lamparter , Julia Lawall , Andrew Morton , linuxppc-dev , Mimi Zohar , Andy Lutomirski , Richard Purdie , Wu Fengguang , Johannes Berg , Michal Marek , Hauke Mehrtens , Mark Brown , Jiri Slaby , Ming Lei , Daniel Vetter , Bjorn Andersson , Felix Fietkau , Roman Pen , Greg KH , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Takashi Iwai , Jeff Mahoney , Hariprasad S , Benjamin Poirier , keescook@google.com Subject: Re: [RFC] fs: add userspace critical mounts event support Message-ID: <20161005014849.GA16348@cloud> References: <20160903174939.GB32345@dtor-ws> <2deae6da-dd43-7bff-e1fd-ffd26946b928@intel.com> <20161005000008.GY3296@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1630 Lines: 30 On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > > idea now. What Marc describes that Josh proposed with signals for > > userspcae seems more aligned with what we likely need > > Quite frankly, I doubt you want a signal. > > You will want to have some way to specify where the firmware files > are. Right now we have "fw_path[]" which is hardcoded except for the > first entry that can be set as a module parameter. But you'd probably > want to expand on that, which implies some /sys or /proc interface. > > And once you do that, wouldn't it make more sense to just make the > "update the firmware path /proc/sys/kernel/fw_path file" make things > re-search for firmware? That could work, but it seems like overkill to allow changing the path, rather than the simpler interface of just telling the one driver "go ahead and direct-load your firmware now". I definitely don't think it should be a system-wide "mount event"; it should be a per-device "go direct-load your firmware" poke from userspace. That would solve the "build-in the driver so it can start waking up slow monitors, but wait to load the firmware until you have a filesystem" problem. (And it would avoid creating some unusual driver-specific late-firmware-load mechanism.) That said, the Chrome OS folks apparently have some mechanism where they mount a tmpfs over /lib/firmware to let userspace choose firmware at runtime, so perhaps the path-changing mechanism would help there. Kees?