Messages in this thread | | | From | Marcel Holtmann <> | Subject | Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option | Date | Sun, 25 May 2008 20:49:38 +0200 |
| |
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.
> Clearly (to me) your wish to prohibit '/'s in the firmware name has to > do with an attempt to force a distiction, to make the firmware a > filename rather than a pathname. But, as you said yourself, the > mapping from firmware name is supposed to be entirely handled in > userland, therefore it doesn't even begin to make sense to distinguish > between filenames and pathnames. You'd have to make assumptions that > (i) the firmware name names files (with built-in firmware, it > doesn't), and, if it is about filenames, (ii) what the pathname > separator character is. 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 :)
> nWouldn't it be better to leave the resolution of firmware names to > content *entirely* up to userland? Say, if userland wants to > implement something very similar to the key-to-data map in-kernel > built-in firmware, this would work just fine, without any artificial > constraints?
And again the grouping into subdirectories should have been fixed in userspace by reading the driver name. The kernel should not do this at all.
Regards
Marcel
| |