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:	Mon, 14 Jul 2008 19:17:27 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jeff@...zik.org
Cc:	dwmw2@...radead.org, david@...g.hm, arjan@...radead.org,
	akpm@...ux-foundation.org, torvalds@...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.

From: Jeff Garzik <jeff@...zik.org>
Date: Mon, 14 Jul 2008 22:12:24 -0400

> David Woodhouse wrote:
> > But since I wanted this tree to be uncontentious and obviously the
> > correct thing to do, I've dropped the drivers/net changes for now
> > anyway.
> > 
> > It's odd that this request has suddenly come out of the blue when we've
> > been using request_firmware() from modules for years already.
> 
> Why is it out of the blue to worry about a working driver suddenly 
> ceasing to work?
> 
> This has nothing to do with request_firmware() itself -- its about 
> having the infrastructure in place so that users do not notice the switch.

And I want to reiterate my adversion to the folks who keep saying
that being opposed to request_firmware() is just like being opposed
to modules.

That's is very far from the truth.

When module support was added, guess what?  I could still build a
completely static kernel image like I always could.

And in fact, to this day, that's what I personally do because that's
how I like my kernels.

But this request_firmware() change does not allow one to get what he
could get before, which is a completely self-contained driver module
object file.

This is the difference between providing an option and making
something mandatory.  This firmware split up is now mandatory.
--
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/