Re: [PATCH] rust: add basic ELF sections parser

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, May 31, 2025 at 09:33:38PM +0900, Alexandre Courbot wrote:
> 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).

Yes, that is what I am referring to, as you all seem to want to do
"complex things without a specific filename choosen".  Look at
Documentation/driver-api/firmware/fallback-mechanisms.rst for the
details there.

Or, better yet, just have your driver name all of the individual files
that must be loaded and then no userspace things are needed.  That "big"
firmware file will have already been split up into the different parts
when you write it out to the filesystem, so no need to parse anything.

If this isn't going to work for some reason, I think we need a better
"this is EXACTLY what we need to send to the hardware for the firmware
image(s) it requires" as I'm totally confused based on the different
people talking on this thread about totally different hypotheticals
(i.e. 12 line elf parsers in C vs. a giant elf parser in rust, random
hypothetical hardware values that userspace "can not know", pointing at
obsolete crazy interfaces like remoteproc that just happen to do crazy
things, etc.)

So step back, come up with a solid design document, and let's start over
please.

thanks,

greg k-h