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



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