Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753334AbcJEAYo (ORCPT ); Tue, 4 Oct 2016 20:24:44 -0400 Received: from mail.kernel.org ([198.145.29.136]:54760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbcJEAYm (ORCPT ); Tue, 4 Oct 2016 20:24:42 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@wotan.suse.de> <20160903174939.GB32345@dtor-ws> <2deae6da-dd43-7bff-e1fd-ffd26946b928@intel.com> <20161005000008.GY3296@wotan.suse.de> From: "Luis R. Rodriguez" Date: Tue, 4 Oct 2016 17:24:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] fs: add userspace critical mounts event support To: Linus Torvalds Cc: 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 , Josh Triplett Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1421 Lines: 33 On Tue, Oct 4, 2016 at 5:12 PM, 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? We can, but re-searching for firmware assumes we cache pending firmware, we currently don't, we just either process sync or async firmware requests. > In other words, the interface has to be something *sensible*. Not some > idiotic ad-hoc "send a signal" (of which that stupid original patch > was just a very odd example). Note that the races are beyond firmware, so all kernel_read_file_from_path() users, as such re-using such old /sys/ interafeces for firmware will not suffice to cover all ground now for the same race for other possible users. Luis