Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754304AbcJEANB (ORCPT ); Tue, 4 Oct 2016 20:13:01 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34037 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751562AbcJEAM7 (ORCPT ); Tue, 4 Oct 2016 20:12:59 -0400 MIME-Version: 1.0 In-Reply-To: <20161005000008.GY3296@wotan.suse.de> 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: Linus Torvalds Date: Tue, 4 Oct 2016 17:12:58 -0700 X-Google-Sender-Auth: n4Fw4tM0Wi5fBEpdoi01mGyoA20 Message-ID: Subject: Re: [RFC] fs: add userspace critical mounts event support To: "Luis R. Rodriguez" 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: 949 Lines: 22 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? 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). Linus