From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Daniel Wagner <daniel.wagner@bmw-carit.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jeff Mahoney <jeffm@suse.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Daniel Wagner <wagi@monom.org>,
Bastien Nocera <hadess@hadess.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Berg <johannes.berg@intel.com>,
Kalle Valo <kvalo@codeaurora.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
David Howells <dhowells@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
David Woodhouse <dwmw2@infradead.org>,
Julia Lawall <julia.lawall@lip6.fr>,
linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
Date: Wed, 3 Aug 2016 15:26:56 -0700 [thread overview]
Message-ID: <20160803222656.GG13516@tuxbot> (raw)
In-Reply-To: <20160803155540.GL3296@wotan.suse.de>
On Wed 03 Aug 08:55 PDT 2016, Luis R. Rodriguez wrote:
> On Wed, Aug 03, 2016 at 08:57:09AM +0200, Daniel Wagner wrote:
> > On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote:
[..]
> > Not sure if I get you here correctly. Is the 'system configurable
> > deterministic file' is a knob which controlled by user space? Or it
> > this something you define at compile time?
>
> I meant at compile time on the kernel. So CONFIG_READ_READY_SENTINEL
> or something like this, and it be a string, which if set then when
> the kernel read APIs are used, then a new API could be introduced
> that would *only* enable reading through once that sentinel has
> been detected by the kernel to allowed through reads. Doing this
> per mount / target filesystem is rather cumbersome given possible
> overlaps in mounts and also pivot_root() being possible, so instead
> targeting simply the fs/exec.c enum kernel_read_file_id would seem
> more efficient and clean but we would need a decided upon set of
> paths per enum kernel_read_file_id as base (or just one path per
> enum kernel_read_file_id). For number of paths I mean the number
> of target directories to look for the sentinel per enum kernel_read_file_id,
> so for instance for READING_FIRMWARE perhaps just deciding on /lib/firmware/
> would suffice, but if this supported multiple paths another option may be
> for the sentinel to also be looked for in /lib/firmware/updates/,
> /lib/firmware/" UTS_RELEASE -- etc. It would *stop* after finding one
> sentinel on any of these paths.
>
> If a system has has CONFIG_READ_READY_SENTINEL it would mean an agreed upon
> system configuration has been decided so that at any point in time reads
> against READING_FIRMWARE using a new kernel_read_file_from_path_sentinel()
> (or something like it) would only allow the read to go through once
> the sentinel has been found for READING_FIRMWARE on the agreed upon
> paths.
>
> The benefit of the sentintel approach is it avoids complexities with
> pivot_root(), and makes the deterministic aspect of the target left
> only to a system-configuration enabled target path / file.
>
This sounds reasonable, it could be configured to wait for a certain
static file or userspace could generate this file once it reaches some
checkpoint.
Just to provide some additional input to "will rootfs mounted be enough
of a sentinel".
In an Android device you have a initramfs that will read an fstab file
and mount /system that holds most firmware, for some platforms
additional firmware will come from a third partition (in the Qualcomm
case mounted in /persist by the same mechanism).
With the sentinel approach one could configure the system either point
it at a file in the last file system to be mounted or have init generate
a file once its done with this; or in the generic configuration just
wait for /lib/firmware to show up.
I like this approach.
> This is just an idea. I'd like some FS folks to review.
>
Regards,
Bjorn
next prev parent reply other threads:[~2016-08-03 22:32 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-28 7:55 [RFC v0 0/8] Reuse firmware loader helpers Daniel Wagner
2016-07-28 7:55 ` [RFC v0 1/8] selftests: firmware: do not abort test too early Daniel Wagner
2016-07-28 7:55 ` [RFC v0 2/8] selftests: firmware: do not clutter output Daniel Wagner
2016-07-28 7:55 ` [RFC v0 3/8] firmware: Factor out firmware load helpers Daniel Wagner
2016-07-28 15:01 ` Dan Williams
2016-07-29 6:07 ` Daniel Wagner
2016-07-28 17:57 ` Dmitry Torokhov
2016-07-29 6:08 ` Daniel Wagner
2016-07-28 7:55 ` [RFC v0 4/8] Input: goodix: use firmware_stat instead of completion Daniel Wagner
2016-07-28 11:22 ` Bastien Nocera
2016-07-28 11:59 ` Daniel Wagner
2016-07-28 12:20 ` Bastien Nocera
2016-07-28 13:10 ` Daniel Wagner
2016-07-28 7:55 ` [RFC v0 5/8] ath9k_htc: " Daniel Wagner
2016-07-28 7:55 ` [RFC v0 6/8] remoteproc: " Daniel Wagner
2016-07-28 7:55 ` [RFC v0 7/8] Input: ims-pcu: " Daniel Wagner
2016-07-28 18:33 ` Dmitry Torokhov
2016-07-28 19:01 ` Bjorn Andersson
2016-07-29 6:13 ` Daniel Wagner
2016-07-30 12:42 ` Arend van Spriel
2016-07-30 16:58 ` Luis R. Rodriguez
2016-07-31 7:23 ` Dmitry Torokhov
2016-08-01 12:26 ` Daniel Wagner
2016-08-01 19:44 ` Luis R. Rodriguez
2016-08-02 5:49 ` Daniel Wagner
2016-08-02 6:34 ` Luis R. Rodriguez
2016-08-02 6:53 ` Daniel Wagner
2016-08-02 7:41 ` Luis R. Rodriguez
2016-08-03 6:57 ` Daniel Wagner
2016-08-03 15:55 ` Luis R. Rodriguez
2016-08-03 16:18 ` Dmitry Torokhov
2016-08-03 17:37 ` Luis R. Rodriguez
2016-08-03 18:40 ` Luis R. Rodriguez
2016-08-03 22:26 ` Bjorn Andersson [this message]
2016-08-03 7:42 ` Dmitry Torokhov
2016-08-03 11:43 ` Arend van Spriel
2016-08-03 15:18 ` Luis R. Rodriguez
2016-08-03 15:35 ` Dmitry Torokhov
2016-08-03 20:42 ` Arend van Spriel
2016-08-03 16:03 ` Luis R. Rodriguez
2016-08-03 17:39 ` Bjorn Andersson
2016-08-03 18:08 ` Luis R. Rodriguez
2016-08-01 19:36 ` Luis R. Rodriguez
2016-08-01 17:19 ` Bjorn Andersson
2016-08-01 19:56 ` Luis R. Rodriguez
2016-08-01 21:34 ` Dmitry Torokhov
2016-07-31 7:17 ` Dmitry Torokhov
2016-07-28 7:55 ` [RFC v0 8/8] iwl4965: " Daniel Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160803222656.GG13516@tuxbot \
--to=bjorn.andersson@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=arend.vanspriel@broadcom.com \
--cc=daniel.wagner@bmw-carit.de \
--cc=dhowells@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hadess@hadess.net \
--cc=jeffm@suse.com \
--cc=johannes.berg@intel.com \
--cc=julia.lawall@lip6.fr \
--cc=kvalo@codeaurora.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mcgrof@kernel.org \
--cc=ohad@wizery.com \
--cc=wagi@monom.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).