On Sunday 25 May 2008 21:01:44 Marcel Holtmann wrote:
quoted text
> 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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/