On May 25, 2008, Marcel Holtmann <marcel@holtmann.org> wrote:

quoted text
> 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.

quoted text
> it is a filename with any directory components.

You can't have it both ways.  Either it is a firmware name in a flat
namespace that userland is supposed to map however it wants to data,
or it is a filename that userland can map in more limited ways
*because* you declared it to be a filename.

Unless...

Are we talking of different things?

I thought you were talking about the string presented to userland to
request firmware to be loaded, but if you're talking about say
pathnames within /sys, I can see how supporting directories et al
could make things more complex and undesirable.

AFAICT by perusing the code for a few seconds, the name within /sys
that is created to receive the firmware code and the string that
userland is requested to resolve to the firmware code are currently
the same, but I don't quite see that there's a reason that requires it
to be so.

quoted text
>> Should '\' be ruled out as well, because someone might want
>> /lib/firmware to be in a FAT filesystem?

quoted text
> Actually the request_firmware() is Linux specific :)

Last I looked Linux supported FAT filesystems.  If someone wanted
/lib/firmware to be FAT, why should this not be permitted?  What's
your point?

quoted text
> And again the grouping into subdirectories should have been fixed in
> userspace by reading the driver name.

You appear to be assuming that driver name is the only reason and
criterium for grouping firmware files.  Any particular reason to force
this one-level grouping model, rather than permitting hierarchical
grouping, that might make more sense?

quoted text
> The kernel should not do this at all.

And AFAICT ATM it doesn't, and that's how it should be.  Let's not
conflate userland implementation with in-kernel naming of firmwares.
These are orthogonal issues.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
--
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/