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 13:07:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>
cc:	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, Marcel Holtmann wrote:
> 
> you don't have to. We extend udev once and then it will always work.

Umm. The thing is, people running new kernels with old user land is not 
just supposed to work, it's _really_ supposed to work.

It's what I do. Something that breaks that has to have damn good reasons 
to break it.

So I do not disagree with Jeff on that point _at_all_. I'm in violent 
agreement with Jeff on the fact that we should not require system updates 
for the kernel to do the right thing.

The thing I disagree with Jeff on is that he then seems to turn that into 
something very negative ("let's not separate the firmware at all").

And I'd much rather just fix it. And that means that if people can point 
to udevd's that get confused - or lack of udevd's entirely - both of which 
sound very likely to me, then we should have a graceful fallback position.

And just supporting the notion of loading the firmware directly sounds 
like an obvious such case. It may not be the _only_ solution, for example, 
which is why I'd actually like to see people point to the _actual_ 
reported problems.

IOW, the problems shouldn't a "don't do this" thing. They should be a "ok, 
that problem happened, we can solve it by doing X".

			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/