linux-kernel - Re: [PATCH] bnx2 - use request

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, 07 Jul 2008 10:03:33 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Michael Chan <mchan@...adcom.com>
Cc:	Bastian Blank <bastian@...di.eu.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bnx2 - use request_firmware()

On Sun, 2008-07-06 at 21:21 -0700, Michael Chan wrote:
> David Woodhouse wrote:
> 
> > But if _Michael_ signs off on it, and if you can provide it
> > in the form
> > used in the firmware-2.6.git tree, with the firmware files added into
> > the firmware/ subdirectory so they're still being shipped with the
> > kernel and the user doesn't have to go find them elsewhere, then I
> > suppose I'll probably take it.
> >
> 
> I cannot sign off on this until I understand more about the impact
> of this change.  Unlike the tg3 firmware which hasn't changed for at
> least 4 or 5 years, the bnx2 firmware is constantly changing and it
> has to match the driver.  For example, we'll be adding multi-tx ring
> to the driver soon and it will require the feature in the firmware.

The firmware will continue to be shipped with the kernel source tree
after this patch. Before applying it, will will update the patch so that
it doesn't just make the driver use request_firmware(), but also adds
the firmware back into the firmware/ directory of the source tree.

We retain the option to build the firmware into the kernel image -- so
if the driver is built in, nothing at all needs to change.

When the driver is built at a module, the 'make modules_install' command
will install the firmware into /lib/firmware where userspace can load
it.

The real concern I see would be if you make an incompatible change in
the firmware when you add the new feature -- so that the older drivers
would no longer work with the new firmware. But mostly, people don't do
that -- I'm guessing that your planned new firmware should work just
fine with older drivers, and the older drivers just won't use the new
feature?

If it _is_ backward-incompatible, that's not really a problem. The
solution is relatively simple; you just change the name of the firmware
file that gets requested by the new driver -- so the old driver
continues to request the old name, and get the firmware that works with
it. It's a bit like an soname in userspace libraries, in that respect.

Please support this patch.

At some point in the future, we'll have a discussion about moving the
firmware/ directory out to a separate, non-GPL'd, repository, where more
firmware can be incorporated. But that's a way off yet.

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