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]

Date:	Tue, 15 Jul 2008 15:59:49 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Frans Pop <elendil@...net.nl>, arjan@...radead.org,
	akpm@...ux-foundation.org, 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.

Linus Torvalds wrote:
> 
> On Tue, 15 Jul 2008, Jeff Garzik wrote:
>> Because people should not be forced to fix all their firmware-related breakage
>> immediately, just to boot 2.6.27.
> 
> You're continuing to make an argument that doesn't seem to backed up with 
> any actual real problems.
> 
> Can you point to real breakage? For real people? 

Already posted a list.

> It sounds like your whole argument literally boils down to "one or two 
> people doing something really stupid or odd cannot just fix their setup".
> 
> What is the real-life situation where copying the firmware with the 
> modules (but still as separate files) actually breaks?

The breakage comes from all the existing-at-this-point-today processes 
that will not copy the firmware with the module.

We're not talking about one or two people, we are talking about projects 
being actively used.

Which in turn means not only those projects need to immediately fix 
stuff to make 2.6.27 work, but users who build and test kernels are left 
to pick up the pieces when their drivers break too.

> IOW, what _is_ this theoretical breakage? And why is it so deadly 
> suddenly? Give us real examples that somehow cannot be fixed?

It's not theoretical, we have already run into non-working drivers due 
to build process changes.  And those were the smart guys, the kernel 
hackers.

All of the examples I have listed can certainly be fixed -- well, except 
the "new kernel, old system" case -- sometimes easily.

* the consequences of the breakage -- 100% non-working driver, possibly 
unbootable system

* the likelihood of breakage -- anything that is not a recent version of 
a mainstream distro WILL have problems, because it simply does not know 
about the firmware that must follow the module whereever it goes.

* the need to immediately add/fix userland and build processes, just to 
keep the same driver set working.

* the need for time, to figure out if you are even affected by this change

* the need for time, to plan the best method to implement firmware 
deployment in your distro

Without firmware-in-module, it is a basic fact that you are forcing 
everyone to fix their stuff, simply to be able to use 2.6.27 like they 
did 2.6.26.

That's unfriendly to distros, users, and kernel testers.

	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/