Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753431AbdF0UYv (ORCPT ); Tue, 27 Jun 2017 16:24:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:42562 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753087AbdF0UYl (ORCPT ); Tue, 27 Jun 2017 16:24:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC89022BDF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mcgrof@kernel.org MIME-Version: 1.0 In-Reply-To: <20170627195239.GL18666@tuxbook> References: <20170623233702.20564-1-jakub.kicinski@netronome.com> <20170626212036.GE21846@wotan.suse.de> <20170626191009.0c11eed0@cakuba.netronome.com> <20170627180341.GT21846@wotan.suse.de> <20170627185915.GK18666@tuxbook> <20170627190853.GX21846@wotan.suse.de> <20170627195239.GL18666@tuxbook> From: "Luis R. Rodriguez" Date: Tue, 27 Jun 2017 13:24:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] firmware: wake all waiters To: Bjorn Andersson Cc: Jakub Kicinski , Ming Lei , "Li, Yi" , "AKASHI, Takahiro" , nbroeking@me.com, Greg Kroah-Hartman , Martin Fuzzey , "Eric W. Biederman" , Dmitry Torokhov , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend van Spriel , "Rafael J. Wysocki" , atull@kernel.org, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , Luca Coelho , Andy Lutomirski , Linus Torvalds , Kees Cook , David Howells , Peter Jones , Hans de Goede , Alan Cox , "Theodore Ts'o" , Paul Gortmaker , mtosatti@redhat.com, Matthew Wilcox , Stephen Boyd , Vikram Mulukutla , lkml , oss-drivers@netronome.com 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: 2115 Lines: 47 On Tue, Jun 27, 2017 at 12:52 PM, Bjorn Andersson wrote: > On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote: >> On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote: >> > Are you saying that each kernel driver should be written so that it will >> > either do direct loading or use firmwared? >> >> Hell No! You can fork firmwared or use whatever the hell bin-foo you want. >> Even if its proprietary and glued with evil rainbow unicorns on it. The dual >> mode, best-effort mode and final-mode devices it implemented are key to what >> you want to mimic as an example to achieve the goal in question. >> > > I'm sorry but your language is totally inappropriate and the reason why > I tend to stay away from firmware-related discussions. I'm sorry if I offended you, the goal here was to use an exaggerated example of what anyone could use to draw in firmware into the kernel. >> Please give that thought / architecture solution a spin and let me know if >> it suffices for your needs. >> > > Which solution do you refer to here? The model of a best-effort and final-mode. > But as I said, in my view, the decision of making the kernel depend on a > user space firmware loading mechanism or direct loading should be that > of the system designer - not the kernel. You get that freedom today. The fallback mechanism *allows* files to be fetched in whatever way possible, by issuing a uevent, its up to userspace to figure out how to gather that and toss it back into the kernel using the sysfs interface. The firemward daemon is nothing but an example *new* daemon which uses a model to address the rootfs / pivot root dilema, as only userspace can know when userspace *is ready*. So its not clear to me yet what your grudge with using firmwared with this new model is exactly. Are you saying you want to *require* the fallback mechanism from the start, so just skipping the direct FS lookup ? That would be a new feature request, and we can certainly consider it, but I'll need Greg to clue me in first on how he'd prefer an API evolution for new features. Luis