From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938804AbcIFRqm (ORCPT ); Tue, 6 Sep 2016 13:46:42 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:35911 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936212AbcIFRqg (ORCPT ); Tue, 6 Sep 2016 13:46:36 -0400 Date: Tue, 6 Sep 2016 10:46:31 -0700 From: Bjorn Andersson To: Linus Torvalds Cc: "Luis R. Rodriguez" , Daniel Vetter , Mimi Zohar , Felix Fietkau , David Woodhouse , Roman Pen , Ming Lei , Andrew Morton , Michal Marek , Greg KH , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Mark Brown , Takashi Iwai , Johannes Berg , Christian Lamparter , Hauke Mehrtens , Josh Boyer , Dmitry Torokhov , Jiri Slaby , Andy Lutomirski , Wu Fengguang , Richard Purdie , Jeff Mahoney , Jacek Anaszewski , Abhay_Salunke@dell.com, Julia Lawall , Gilles.Muller@lip6.fr, nicolas.palix@imag.fr, Tom Gundersen , Kay Sievers , David Howells , Alessandro Rubini , Kevin Cernekee , Kees Cook , Jonathan Corbet , Thierry Martinez , cocci@systeme.lip6.fr, linux-serial@vger.kernel.org, "open list:DOCUMENTATION" , linuxppc-dev Subject: Re: [RFC] fs: add userspace critical mounts event support Message-ID: <20160906174630.GB15161@tuxbot> References: <1466117661-22075-1-git-send-email-mcgrof@kernel.org> <1466117661-22075-3-git-send-email-mcgrof@kernel.org> <20160824203901.GT3296@wotan.suse.de> <20160825194133.GC3296@wotan.suse.de> <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@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 On Fri 02 Sep 21:11 PDT 2016, Linus Torvalds wrote: Linus, I reversed the order of your questions/answers to fit my answer better. > On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: > > > > Thoughts ? > What are the drivers that need this, and why can't those drivers just > be fixed to not do braindead things? > I have several cases where remoteproc drivers are used boot DSPs upon boot of the device, but the firmware files are way too big for being stored in initramfs and all consumers of the provided services are (semi-) probable as the remote processor is booted. I.e. we need some way to figure out when these files become available so we can bring these remote processors up. > It's basically the kernel giving up, and relying on user space to give > a single flag, and it's broken nasty crap. Worse, it's broken nasty > crap with a user interface, so we'll be stuck with it forever. Please > no. > There are several cases where there granularity of a single flag is not enough and we do already have a working mechanism for relying on user space to inform the kernel that firmware is available: CONFIG_FW_LOADER_USER_HELPER_FALLBACK Another available solution is, as you say, using kernel modules. But I really do not like the deployment issues that comes with kernel modules during development. (The firmware and remoteproc driver normally does not have the same flow through a development process) > > I really think this is a horrible hack. > I agree, but that said, I would appreciate a automagical mechanism that would relieve user space from having to signal to the kernel that the firmware partition has been mounted. Regards, Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [RFC] fs: add userspace critical mounts event support Date: Tue, 6 Sep 2016 10:46:31 -0700 Message-ID: <20160906174630.GB15161@tuxbot> References: <1466117661-22075-1-git-send-email-mcgrof@kernel.org> <1466117661-22075-3-git-send-email-mcgrof@kernel.org> <20160824203901.GT3296@wotan.suse.de> <20160825194133.GC3296@wotan.suse.de> <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Linus Torvalds Cc: "Luis R. Rodriguez" , Daniel Vetter , Mimi Zohar , Felix Fietkau , David Woodhouse , Roman Pen , Ming Lei , Andrew Morton , Michal Marek , Greg KH , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Mark Brown , Takashi Iwai , Johannes Berg , Christian Lamparter , Hauke Mehrtens , Josh Boyer , Dmitry List-Id: linux-serial@vger.kernel.org On Fri 02 Sep 21:11 PDT 2016, Linus Torvalds wrote: Linus, I reversed the order of your questions/answers to fit my answer better. > On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: > > > > Thoughts ? > What are the drivers that need this, and why can't those drivers just > be fixed to not do braindead things? > I have several cases where remoteproc drivers are used boot DSPs upon boot of the device, but the firmware files are way too big for being stored in initramfs and all consumers of the provided services are (semi-) probable as the remote processor is booted. I.e. we need some way to figure out when these files become available so we can bring these remote processors up. > It's basically the kernel giving up, and relying on user space to give > a single flag, and it's broken nasty crap. Worse, it's broken nasty > crap with a user interface, so we'll be stuck with it forever. Please > no. > There are several cases where there granularity of a single flag is not enough and we do already have a working mechanism for relying on user space to inform the kernel that firmware is available: CONFIG_FW_LOADER_USER_HELPER_FALLBACK Another available solution is, as you say, using kernel modules. But I really do not like the deployment issues that comes with kernel modules during development. (The firmware and remoteproc driver normally does not have the same flow through a development process) > > I really think this is a horrible hack. > I agree, but that said, I would appreciate a automagical mechanism that would relieve user space from having to signal to the kernel that the firmware partition has been mounted. Regards, Bjorn