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: <1216082213.27455.109.camel@shinybook.infradead.org>
Date:	Mon, 14 Jul 2008 17:36:53 -0700
From:	David Woodhouse <dwmw2@...radead.org>
To:	david@...g.hm
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <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.

On Mon, 2008-07-14 at 17:06 -0700, david@...g.hm wrote:
> On Mon, 14 Jul 2008, Arjan van de Ven wrote:
> 
> > On Mon, 14 Jul 2008 16:41:19 -0700
> > Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> >> On Mon, 14 Jul 2008 16:23:26 -0700
> >> David Woodhouse <dwmw2@...radead.org> wrote:
> >>
> >>> Linus, please pull from the for-2.6.27 branch of:
> >>> 	git://git.infradead.org/users/dwmw2/firmware-2.6.git
> >>> for-2.6.27
> >>
> >> The firmware flamewars seem to have subsided lately.  Is everyone
> >> happy with this now?
> >>
> >
> > this seems to have left the contentious pieces out....
> 
> almost, the one thing that this could have done would be to offer an 
> option to bundle the firmware with the module. currently it offers the 
> option to load the firmware at the same time as the module, not _quite_ 
> the same thing.

I see no real point in that. If you have userspace to load modules, then
you have userspace to load firmware.

We made 'make modules_install' install the firmware in /lib/firmware for
you at the same time as it installs the modules, to avoid problems if
people forgot to run 'make firmware_install'. That really ought to be
enough.

I know Jeff complained that it wasn't, and insisted that he _needed_ to
be able to scp a single .ko file around which contained both, and the
world was broken if he could not -- but I disagree with him.

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.

> there was also the issue that was raised about how to handle firmware 
> during suspend/resume. I don't remember seeing a happy solution to that 
> one.

My b43 seems to work fine on suspend/resume, as do most other modern
drivers which use request_firmware(). There is certainly no fundamental,
generic problem with suspend/resume vs. the firmware loader.

If you see a problem with a specific driver which we've converted, do
please point it out.

-- 
dwmw2

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ