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:	Wed, 16 Jul 2008 00:20:48 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	david@...g.hm, Marcel Holtmann <marcel@...tmann.org>,
	David Woodhouse <dwmw2@...radead.org>, 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 Tuesday 15 July 2008, you wrote:
> 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_?

Because in most cases users do not write and maintain the scripts used to 
build custom kernels themselves. They use (huge and way too) tools like 
Debian's 'make-kpkg' for that.

Because users may want to build a custom 2.6.27 in for example a Debian 
Etch environment using the make-kpkg package that is available in that 
release of Debian. Or even a Debian Lenny environment (Lenny is about to 
be frozen so is very unlikely to include whatever may be needed for 
this).

Why is it good to extend the lifetime of the i386 and amd64 symlinks for 
x86 images by an extra few years so that older versions of kernel 
packaging tools - like make-kpkg - don't break, but is breaking the exact 
same tools with this firmware change suddenly OK?

Users _want_ to be able to build new kernels in older environments. Why 
take that option away from them? Why force them through the pain of 
partial upgrades of their userspace if it can so easily be avoided?

>From my PoV adding this option is a no-brainer: if Jeff is willing to do 
the work, then what harm can it do? The benefits to me are obvious.
I really don't get what you have against it.

Cheers,
FJP

P.S. Sorry to keep coming up with Debian examples, but that's the 
environment I know.
--
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/