Re: [PATCH v3] firmware_loader: allow firmware_class.path to take multiple paths

[Jeff Layton]

On Thu, 2026-03-19 at 16:30 +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 19, 2026 at 02:13:09PM +0000, Michal Grzedzicki wrote:
> > 
> > > On 19 Mar 2026, at 11:47, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > > 
> > > On Thu, 2026-03-19 at 12:39 +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Mar 19, 2026 at 07:34:46AM -0400, Jeff Layton wrote:
> > > > > On Thu, 2026-03-19 at 07:23 +0100, Greg Kroah-Hartman wrote:
> > > > > > On Wed, Mar 18, 2026 at 03:54:02PM -0400, Jeff Layton wrote:
> > > > > > > Refactor fw_get_filesystem_firmware() by extracting the per-path
> > > > > > > firmware loading logic into a new fw_try_firmware_path() helper.
> > > > > > > 
> > > > > > > Use this helper to parse fw_path_para for ':'-separated paths,
> > > > > > > trying each one before falling through to the default firmware
> > > > > > > search paths. This allows users to specify multiple custom firmware
> > > > > > > directories via firmware_class.path, e.g.:
> > > > > > > 
> > > > > > >  firmware_class.path=/custom/path1:/custom/path2
> > > > > > > 
> > > > > > > A backslash can be used as an escape character, allowing a literal
> > > > > > > ':' ("\:") or literal '\' ("\\") to be embedded in a pathname.
> > > > > > 
> > > > > > This is a mess, what could go wrong embedding another parser in the
> > > > > > kernel :)
> > > > > > 
> > > > > > Let's step back, why is this needed at all?  The kernel already supports
> > > > > > multiple standard locations for firmware paths, and one custom location.
> > > > > > Why do we now need more than that?  What changed to require this and who
> > > > > > is going to use it (and support it, and actually test it?)
> > > > > > 
> > > > > 
> > > > > We have at least one internal user that requested the ability to do
> > > > > this. I'll see if they can articulate their use-case better.
> > > > 
> > > > Please do.
> > > > 
> > > 
> > > Michal said he'll outline his use-case.
> > 
> > 
> > Internally, we distribute firmware binaries as read-only snapshots, and a system may have more than one. Without this feature, we must maintain a symlink farm to merge multiple snapshots into a single path. We would love to remove this workaround and switch to just passing multiple paths.
> > 
> > Also a common pattern I seen in vendor shell scripts is temporarily setting firmware_class.path to the current working directory, loading the module, and then restoring firmware_class.path to its previous value, with this feature it could be made safer.
> 
> How would putting a bunch of different filepaths be "safer"?  A shell
> script will have to read the value, append their path to it, and then
> write it back? 
> 

It's safer in that you don't have to have a shell script monkeying with
the path string.

> And how will that ever work given that they will not
> know if this is a kernel version that can support multiple paths in a
> single value?
> 
> I think if you are going to change the way the option works, it needs to
> be renamed so that everyone "knows" they can rely on it, otherwise no
> one will use it.
> 

That is a valid point though. I'd be open to adding a separate module
option for this. Some name ideas:

paths=
searchpath=
search=

Anyone have opinions?
-- 
Jeff Layton <jlayton@xxxxxxxxxx>