From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754380AbcICRwn (ORCPT ); Sat, 3 Sep 2016 13:52:43 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:33138 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753791AbcICRwk (ORCPT ); Sat, 3 Sep 2016 13:52:40 -0400 Date: Sat, 3 Sep 2016 10:49:39 -0700 From: Dmitry Torokhov To: Linus Torvalds Cc: "open list:DOCUMENTATION" , cocci@systeme.lip6.fr, Jacek Anaszewski , David Woodhouse , Christian Lamparter , Julia Lawall , Andrew Morton , linuxppc-dev , Mimi Zohar , Andy Lutomirski , Richard Purdie , Wu Fengguang , Johannes Berg , "Luis R. Rodriguez" , Michal Marek , Hauke Mehrtens , Mark Brown , Jiri Slaby , Ming Lei , Daniel Vetter , Kevin Cernekee , Jeff Mahoney , Greg KH , Bjorn Andersson , Jonathan Corbet , Felix Fietkau , David Howells , Vikram Mulukutla , Alessandro Rubini , Tom Gundersen , Kees Cook , Takashi Iwai , Gilles.Muller@lip6.fr, linux-serial , Roman Pen , Kay Sievers , Stephen Boyd , nicolas.palix@imag.fr, "Abhay_Salunke@dell.com" , Linux Kernel Mailing List , Thierry Martinez , Josh Boyer Subject: Re: [RFC] fs: add userspace critical mounts event support Message-ID: <20160903174939.GB32345@dtor-ws> References: <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.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 02, 2016 at 09:41:18PM -0700, Linus Torvalds wrote: > On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote: > > > > Like what? Some devices do need to have firmware loaded so we know > > their capabilities, so we really can't push the firmware loading into > > "open". > > So you > (a) document that Document that device may come up half-broken? Not sure how that would help end user. > (b) make the driver only build as a module Unfortunately module loading and availability of firmware is very loosely coupled. Of course, if you only load modules from the same partition that your firmware is on you can get away with it, but if some of the modules are in initramfs and firmware is on final root fs then it still does not work. And populating also initramfs with firmware that might be used once in a 1000 boots is somewhat wasteful. That is not talking about systems that do not wish to use modules for one reason or another, or even more esoteric setups where non-essential for boot firmware can be mounted later over nfs, etc, etc. > (c) make sure the module and the firmware go together I do not think it is always possible. Quite often it is though, at the expense of increasing kernel/initramfs size. > > End of problem. > > Why make up random interfaces for crazy stuff? Because we want a solution that works well for all cases, simple and complex. This includes allowing drivers to be built into the kernel but allow them waiting for additional data (config/firmware) that may become available later in the game. We just need to be able to tell them when it does not make sense to wait anymore as the data they want is not coming, and do it more reliably then simply declaring 10 or 30 or 300 seconds time out. Thanks. -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [RFC] fs: add userspace critical mounts event support Date: Sat, 3 Sep 2016 10:49:39 -0700 Message-ID: <20160903174939.GB32345@dtor-ws> References: <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Linus Torvalds Cc: "open list:DOCUMENTATION" , Takashi Iwai , Daniel Vetter , Ming Lei , Jeff Mahoney , Kay Sievers , Bjorn Andersson , David Howells , Christian Lamparter , cocci@systeme.lip6.fr, Josh Boyer , Jonathan Corbet , Kevin Cernekee , Thierry Martinez , linux-serial , Jiri Slaby , Mimi Zohar , Alessandro Rubini , Stephen Boyd , Kees Cook , Hauke Mehrtens , nicolas.palix@imag.fr, "Abhay_Salunke@dell.com" , Julia Lawall List-Id: linux-serial@vger.kernel.org On Fri, Sep 02, 2016 at 09:41:18PM -0700, Linus Torvalds wrote: > On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote: > > > > Like what? Some devices do need to have firmware loaded so we know > > their capabilities, so we really can't push the firmware loading into > > "open". > > So you > (a) document that Document that device may come up half-broken? Not sure how that would help end user. > (b) make the driver only build as a module Unfortunately module loading and availability of firmware is very loosely coupled. Of course, if you only load modules from the same partition that your firmware is on you can get away with it, but if some of the modules are in initramfs and firmware is on final root fs then it still does not work. And populating also initramfs with firmware that might be used once in a 1000 boots is somewhat wasteful. That is not talking about systems that do not wish to use modules for one reason or another, or even more esoteric setups where non-essential for boot firmware can be mounted later over nfs, etc, etc. > (c) make sure the module and the firmware go together I do not think it is always possible. Quite often it is though, at the expense of increasing kernel/initramfs size. > > End of problem. > > Why make up random interfaces for crazy stuff? Because we want a solution that works well for all cases, simple and complex. This includes allowing drivers to be built into the kernel but allow them waiting for additional data (config/firmware) that may become available later in the game. We just need to be able to tell them when it does not make sense to wait anymore as the data they want is not coming, and do it more reliably then simply declaring 10 or 30 or 300 seconds time out. Thanks. -- Dmitry