Re: [RFC] fs: add userspace critical mounts event support

From: Josh Triplett <josh@joshtriplett.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"Herbert, Marc" <marc.herbert@intel.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Jacek Anaszewski <j.anaszewski@samsung.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Christian Lamparter <chunkeey@googlemail.com>,
	Julia Lawall <Julia.Lawall@lip6.fr>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Richard Purdie <rpurdie@rpsys.net>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Michal Marek <mmarek@suse.com>, Hauke Mehrtens <hauke@hauke-m.de>,
	Mark Brown <broonie@kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Ming Lei <ming.lei@canonical.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Felix Fietkau <nbd@nbd.name>, Roman Pen <r.peniaev@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vikram Mulukutla <markivx@codeaurora.org>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	Takashi Iwai <tiwai@suse.de>, Jeff Mahoney <jeffm@suse.com>,
	Hariprasad S <hariprasad@chelsio.com>,
	Benjamin Poirier <bpoirier@suse.de>,
	keescook@google.com
Subject: Re: [RFC] fs: add userspace critical mounts event support
Date: Tue, 4 Oct 2016 18:48:49 -0700	[thread overview]
Message-ID: <20161005014849.GA16348@cloud> (raw)
In-Reply-To: <CA+55aFx=hzXhrHQO4-0Jnd1ML4dismQ8qggvSp0yccSRW6qH3A@mail.gmail.com>

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 <mcgrof@kernel.org> 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?