linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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: <487CF70C.1030309@garzik.org>
Date:	Tue, 15 Jul 2008 15:14:20 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Theodore Tso <tytso@....edu>, Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, david@...g.hm,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from	in-kernel,
 use it in more drivers.

Theodore Tso wrote:
> On Tue, Jul 15, 2008 at 02:44:46PM -0400, Jeff Garzik wrote:
>> All of the regressions examples I am citing are cured by  
>> firmware-in-module, because they are all examples of problems that occur  
>> when you remove the ability to reproduce the same functional pieces as  
>> 2.6.26.
> 
> Jeff,
> 
> 	I think you've said this before, but let me try to help you
> cut to the chase.  You are willing to *implement*
> firmware-in-the-module for request_firmware(), but you want a
> commitment that David Woodhouse and Linus will accept such a patch
> before you go off and write it.  Is that right?
> 
> 	If so, may I suggest you start implementing, instead of
> sending e-mails?  For all the time people have spent arguing about it,
> maybe it could have been implemented already.

Already started, in fact, since Linus said he would not reject it out of 
hands.

Obviously that is not acceptance; I know as well as any that acceptance 
does not occur until the moment of upstream merge.

> 	Once it has been implemented, do you have any further
> objections aka ideas about how request_firmware() could be improved?

Further objections?  None major.

The two other minor problems I feel need solving, but are not related to 
breakage or regressions, are:

1) firmware should be able to live alongside the driver.  We don't need 
to start growing firmware/net alongside drivers/net, firmware/scsi 
alongside drivers/scsi, firmware/char alongside drivers/char, etc.

2) firmware should be able to be shipped in final format (binary), 
rather than ihex.

I feel strongly that 2.6.27 should not be released without 
firmware-in-module, for all the reasons mentioned in these threads. 
It's a major regression, IMO, without firmware-in-module ability.

The other stuff (#1, #2 in list above) is small potatoes.

	Jeff

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