linux-kernel - Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <orzlqdyc77.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Mon, 26 May 2008 00:30:04 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Johannes Berg <johannes@...solutions.net>,
	David Woodhouse <dwmw2@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
	alan@...rguk.ukuu.org.uk, Abhay Salunke <Abhay_Salunke@...l.com>,
	kay.sievers@...y.org, Takashi Iwai <tiwai@...e.de>,
	Michael Buesch <mb@...sch.de>
Subject: Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

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

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

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.

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

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?

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

> 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@...d.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/