Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

From: Alexandre Oliva
Date: Sun May 25 2008 - 23:32:15 EST


On May 25, 2008, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:

> Hi Alexandra,
>>> in the early days we had something like three drivers using the
>>> request_firmware() and it was understood between the authors what the
>>> filename was meant for.
>>
>> You're contradicting yourself. Is it a filename, or is it not?
>> Earlier, you said it wasn't, it was just a name that userspace was
>> supposed to map to a filename. Now, you're saying it is a filename.

> it is a filename with any directory components.

You can't have it both ways. Either it is a firmware name in a flat
namespace that userland is supposed to map however it wants to data,
or it is a filename that userland can map in more limited ways
*because* you declared it to be a filename.

Unless...

Are we talking of different things?

I thought you were talking about the string presented to userland to
request firmware to be loaded, but if you're talking about say
pathnames within /sys, I can see how supporting directories et al
could make things more complex and undesirable.

AFAICT by perusing the code for a few seconds, the name within /sys
that is created to receive the firmware code and the string that
userland is requested to resolve to the firmware code are currently
the same, but I don't quite see that there's a reason that requires it
to be so.

>> Should '\\' be ruled out as well, because someone might want
>> /lib/firmware to be in a FAT filesystem?

> Actually the request_firmware() is Linux specific :)

Last I looked Linux supported FAT filesystems. If someone wanted
/lib/firmware to be FAT, why should this not be permitted? What's
your point?

> And again the grouping into subdirectories should have been fixed in
> userspace by reading the driver name.

You appear to be assuming that driver name is the only reason and
criterium for grouping firmware files. Any particular reason to force
this one-level grouping model, rather than permitting hierarchical
grouping, that might make more sense?

> The kernel should not do this at all.

And AFAICT ATM it doesn't, and that's how it should be. Let's not
conflate userland implementation with in-kernel naming of firmwares.
These are orthogonal issues.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ÂSÃ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/