linux-kernel - Re: [Ksummit-2008-discuss] RFC: Moving firmware blobs out of the kernel.

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:	Fri, 30 May 2008 10:47:15 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	James.Bottomley@...senPartnership.com,
	ksummit-2008-discuss@...ts.linux-foundation.org,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [Ksummit-2008-discuss] RFC: Moving firmware blobs out of the
	kernel.

Em Fri, May 30, 2008 at 02:04:18AM +0300, David Woodhouse escreveu:
> It's not as if it's hard to set CONFIG_BUILTIN_FIRMWARE_DIR to point to
> your checkout of the linux-firmware repository, and build your kernel
> with _whatever_ firmware you choose. You end up with _more_ choice, not
> less.
> 
> And on the rare occasion that we really do have an incompatible change
> of firmware/kernel interaction from one kernel to the next, it really
> isn't difficult to add a version number to the name of the firmware
> file, and ship both old and new firmwares in the firmware tree for a
> while. That's a bogus argument, even if people _do_ manage to come up
> with a better example for it, where their firmware has actually changed
> in the last couple of years.

While updating the bnx2 driver on a 2.6.24.7 based rpm and after reading
some of your messages...

commit df7f1ed6b85b936a4dd341c48e30aa207697997c
Author: Michael Chan <mchan@...adcom.com>
Date:   Tue Jan 29 21:38:06 2008 -0800

    [BNX2]: Update firmware.
    
    Update firmware to support programmable flow control.
    
    Signed-off-by: Michael Chan <mchan@...adcom.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

After this bnx2.c would be updated to have a:

MODULE_FIRMWARE_DEFAULT("df7f1ed6b85b936a4dd341c48e30aa207697997c");

to be obtained from firmware.git, and if some chip revisions needed
something different we could have a MODULE_FIRMWARE_PCI(vendor, product,
older-git-object) or something along these lines.

Some drivers could well prefer a more loose keying scheme, like
"foo-firmware-v2" and get the latest version of this from firmware.git.

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