Messages in this thread | | | From | Michael Buesch <> | Subject | Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option | Date | Sun, 25 May 2008 21:09:44 +0200 |
| |
On Sunday 25 May 2008 21:01:44 Marcel Holtmann wrote: > Hi Michael, > > >>> 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. > >> > >> 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? > >> > >> 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? > > > > One additional thing is to make sure the usability of the whole stuff > > is not reduded. Currently I can do: > > > > modprobe b43 fwpostfix=-open > > # work with opensource firmware in b43-open/ > > rmmod b43 > > modprobe b43 > > # work with standard firmware in b43/ > > > > So it is really simple to switch between different flavours of > > firmware. > > It is _not_ acceptable to change an udev configuration file all the > > time, > > if you want to use another firmware. One needs to frequently switch > > between firmware versions when developing firmware code. > > we might should write down what everybody expects from a firmware > loading mechanism. > > I would like to see generic support for these kind of things. Not > duplicated functionality in every driver.
Additionally the driver must be able to use different versions of firmware. I'm going to implement fw probing in b43 like: first probe propietary firmware (in b43/) if that doesn't exist probe open firmware (in b43-open/)
These different versions of one firmware _must_ live within different directories in userspace. I don't care about where this policy decision is made. But the new policy default must match the current policy in any case.
-- Greetings Michael.
| |