From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Greg KH" <gregkh@linuxfoundation.org>, "Timur Tabi" <timur@kernel.org>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] rust: add basic ELF sections parser
Date: Sat, 31 May 2025 21:33:38 +0900 [thread overview]
Message-ID: <DAACKTM8B9A1.3SI9LRGNMSBH3@nvidia.com> (raw)
In-Reply-To: <2025053148-gore-badass-1d1d@gregkh>
Hi Greg,
On Sat May 31, 2025 at 2:45 PM JST, Greg KH wrote:
> On Fri, May 30, 2025 at 01:10:50PM -0500, Timur Tabi wrote:
>> On Fri, May 30, 2025 at 10:42 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>> >
>> > On Fri, May 30, 2025 at 11:34:02PM +0900, Alexandre Courbot wrote:
>> > > So to try to answer your question, I am not disagreeing that userspace
>> > > is capable of doing what we currently do in the kernel. My follow-up
>> > > questions to that are: how do we command userspace to do that work for
>> > > us when we request the firmware, how do we provide the result to the
>> > > kernel, and is this something that distros can adopt easily? I'm happy
>> > > to consider doing things this way, but would need a few pointers to look
>> > > into.
>> >
>> > Again, look at how your firmware for your devices in your laptop are
>> > loaded today.
>
> Note, I am talking about non-gpu firmare images here (wifi, usb
> controllers, etc.) that are using the firmware download subsystem for
> ages as examples of what to look at as to how to trigger a firmware
> image to be loaded by userspace into the device.
I would really appreciate it if you could point me precisely to one
example (a link, a function, a file) of what you are describing because
I'm starting to wonder whether we are talking about the same thing.
Previously I mentioned udev and CONFIG_FW_LOADER_USER_HELPER, but you
haven't confirmed whether that was what you had in mind or not. Assuming
that udev is involved, I tried to snoop events while a
`request_firwmare` call is performed using `udevadm monitor`, but that
revealed no event related to firmware loading. Then looking deeper into
the kernel documentation confirmed that the kernel does indeed a direct
filesystem lookup in request_firmware [1]. IOW, the kernel looks for the
requested file, and if it cannot find it it's game over. This matches my
observations with udevadm, as I tried requesting a non-existing file and
no uevent was generated. I don't see what user-space can do here.
I also tried to look up this "firmware download subsystem" you
mentioned, but couldn't find anything under that name - I suspect you
are talking about the sysfs loading mechanism, but AFAIU this depends on
CONFIG_FW_LOADER_USER_HELPER which doesn't seem to be widely enabled
(not on my distro at least).
What I am trying to say is that I am more than willing to look into
having this work done by user-space, but despite this conversation and
hours of research and testing I still don't have even a thread to
unravel. If you know the answer for how to do this, please share it.
[1] https://docs.kernel.org/driver-api/firmware/direct-fs-lookup.html
next prev parent reply other threads:[~2025-05-31 12:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 6:03 [PATCH] rust: add basic ELF sections parser Alexandre Courbot
2025-05-15 7:38 ` Greg KH
2025-05-15 8:32 ` Alexandre Courbot
2025-05-15 11:25 ` Alexandre Courbot
2025-05-15 11:42 ` Greg KH
2025-05-15 13:09 ` Alexandre Courbot
2025-05-15 14:30 ` Timur Tabi
2025-05-15 19:17 ` John Hubbard
2025-05-16 13:15 ` Greg KH
2025-05-16 13:26 ` Alexandre Courbot
2025-05-16 13:32 ` Greg KH
2025-05-16 13:35 ` Danilo Krummrich
2025-05-16 14:35 ` Alexandre Courbot
2025-05-16 16:01 ` Danilo Krummrich
2025-05-16 19:00 ` John Hubbard
2025-05-17 10:13 ` Danilo Krummrich
2025-05-17 13:41 ` Alexandre Courbot
2025-05-16 16:28 ` Timur Tabi
2025-05-17 0:51 ` Alexandre Courbot
2025-05-29 6:53 ` Alexandre Courbot
2025-05-29 8:01 ` Greg KH
2025-05-30 0:58 ` Alexandre Courbot
2025-05-30 6:21 ` Greg KH
2025-05-30 6:56 ` Alexandre Courbot
2025-05-30 9:00 ` Greg KH
2025-05-30 6:22 ` Greg KH
2025-05-30 6:59 ` Alexandre Courbot
2025-05-30 9:01 ` Greg KH
2025-05-30 14:34 ` Alexandre Courbot
2025-05-30 15:42 ` Greg KH
2025-05-30 18:10 ` Timur Tabi
2025-05-31 5:45 ` Greg KH
2025-05-31 10:17 ` Timur Tabi
2025-05-31 12:25 ` Greg KH
2025-05-31 14:38 ` Timur Tabi
2025-05-31 15:28 ` Danilo Krummrich
2025-06-01 7:48 ` Greg KH
2025-05-31 12:33 ` Alexandre Courbot [this message]
2025-05-31 13:30 ` Greg KH
2025-06-01 12:23 ` Alexandre Courbot
2025-06-13 3:32 ` Alexandre Courbot
2025-06-24 14:26 ` Greg KH
2025-06-24 14:51 ` Danilo Krummrich
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=DAACKTM8B9A1.3SI9LRGNMSBH3@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=timur@kernel.org \
--cc=tmgross@umich.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.