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

[Jeff Layton]

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.

> > > We really want to make the number of firmware paths less, not more.  But
> > > if we _really_ need multiple paths, isn't it simpler to just have an
> > > array of paths here, not be forced to parse escape codes like you are
> > > now doing?
> > > 
> > 
> > How would one feed an array of paths to the module without delimiting
> > them in some fashion?
> 
> I don't know, but once you start attempting to "escape" things, the
> complexity goes up a lot and makes me think that this all isn't a good
> idea :)
> 

Fair point, but the escaping here is pretty tame -- It's only escaping
':' and '\'. For better or worse, UNIX has very few characters that are
not allowed to be embedded in filenames, so our options for doing this
are somewhat limited.

If we really don't want to deal with escaping, then another option
might be to add a fixed number of path strings "slots" as parameters
(i.e. path1=/foo,path2=/bar,path3=...).

That seems uglier and more limiting than dealing with escapes though.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>