linux-kernel - Re: [PATCH][RFC] request_firmware examples and MODULE

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: <1157441620.24916.5.camel@localhost>
Date:	Tue, 05 Sep 2006 09:33:40 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Victor Hugo <victor@...go.net>
Cc:	linux-kernel@...r.kernel.org,
	Victor Castro <victorhugo83@...oo.com>
Subject: Re: [PATCH][RFC] request_firmware examples and MODULE_FIRMWARE

Hi Victor,

> Also, I'd like to comment on Jon Masters push to include the  
> MODULE_FIRMWARE api addition.  I strongly believe that policy should  
> not be included in driver code, in this case it's in the form of a  
> filename.
> 
> The firmware loader currently needs a filename passed to it so it can  
> then pass the $FIRMWARE environment variable to the hotplug script.   
> This is ok if you provide a generic filename like "firmware.bin" and  
> then let the hotplug script worry about version numbers, i.e.  
> "firmware-x.y.z.bin"
> 
> MODULE_FIRMWARE should be used to provide the generic filenames and  
> which order the files should be loaded (request_firmware can be  
> called various times), but I think its bad to have to change the  
> driver everytime a new firmware version is released.

actually it has never been really a filename. It was a simple pattern
that the initial hotplug script and later the udev script mapped 1:1 to
a filename on your filesystem. If you check the mailing list archives of
LKML and linux-hotplug you will see that I always resisted in allowing
drivers to include a directory path in that call. A couple of people
tried this and it is not what it was meant to be.

The MODULE_FIRMWARE approach simply makes this pattern visible via
modinfo, because otherwise you would have to scan the source code to
find this pattern. And to make it use you have to apply the same policy
the firmware script is applying when choosing the file. Currently this
is a 1:1 mapping.

Regards

Marcel

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