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

[Marcel Holtmann]

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.

Regards

Marcel

--
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/