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: <alpine.LFD.1.10.0807151436400.2867@woody.linux-foundation.org>
Date:	Tue, 15 Jul 2008 14:43:53 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	david@...g.hm
cc:	Marcel Holtmann <marcel@...tmann.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Frans Pop <elendil@...net.nl>, jeff@...zik.org,
	arjan@...radead.org, akpm@...ux-foundation.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.

On Tue, 15 Jul 2008, david@...g.hm wrote:
> 
> a kernel compiled with this option would just drop-in to an older distro with
> zero impact. newer distros that have updated their userspace tools could
> compile with different options and have the firmware seperate.

The 'zero impact' is what doesn't make sense here.

You are supposed to be able to run ol distributions, yes.

But that doesn't mean that you can necessarily just plop things in the 
same way as you always did before.

For example, you have to rewrite your distro's initrd if you are using 
modules. You cannot just re-use the modules in the distro initrd. So doing 
a new kernel has _never_ been 'zero impact' in the sense that you could 
just switch vmlinux files around.

(Btw, I personally actually want my kernel to be _truly_ zero impact, but 
that also means that I don't use modules - because that way I really can 
avoid changing even the initrd image too. But that also already works)

Why is it suddenly so important that a kernel be 'zero impact' for that 
module case, when it's never been zero impact for that case before? You 
had to rewrite the initrd to begin with, but now you're not willing to do 
it again, just because you have to rewrite it slightly _differently_?

THAT is what I find so odd. The inability to accept just a slight change 
in kernel build.

But whatever. This really isn't worth it. The request_firmware() thing 
will clearly happen regardless, and as long as the backwards compat code 
is small and Jeff writes it, what do I care? Even if I think it looks 
largely pointless..

			Linus

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