lkml.org 
[lkml]   [2008]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option
Date
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



\
 
 \ /
  Last update: 2008-05-25 21:05    [W:0.164 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site