linux-kernel - Re: [PATCH] ip2: 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] [day] [month] [year] [list]

Date:	Mon, 16 Jun 2008 23:01:39 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	jaswinder@...radead.org
Subject: Re: [PATCH] ip2: use request_firmware()

On Mon, 2008-06-16 at 17:39 -0400, Jeff Garzik wrote:
> Alan Cox wrote:
> >> Extracting the firmware:  good
> >>
> >> Scattering a /single/ driver across multiple directories in the kernel 
> >> tree:  bad
> > 
> > I'd equally argue that putting all the firmware in one place is more
> > logical than smearing it around the tree.
> 
> Logical for whom?  Drivers have always been self-contained... until now.
> 
> This separation certainly does not make things _easier_ for users, our 
> reason for existence.  This separation certainly does not make it easier 
> to drop in a driver with a firmware, i.e. not easier on driver 
> developers.  It is one more PITA detail when copying a driver from one 
> kernel to another, or shipping the driver out of tree.

When you're doing either of those things, you should be letting
request_firmware() do its job. You shouldn't _need_ to build that
firmware into your static kernel image.

And if you _do_ want to build arbitrary firmware into your kernel image,
you can do that with ease -- with the CONFIG_BUILTIN_FIRMWARE option you
can include _whatever_ files you like.

> There are good reasons why the Makefile rules, Kconfig rules, C source 
> code and headers for a driver all live together...  moving the firmware 
> elsewhere is strangely, given that a driver simply /does not work/ 
> without the firmware.

We already cope with having separate directories for include/, and with
having some stuff split between arch/ and generic locations. In fact,
not only do we 'cope', but we _prefer_ it that way. It's logical. And
that's for kernel code which really does get modified in lock-step.

We almost _never_ change firmware and driver in lock-step as we do other
code. Maybe we'd like to -- but since the firmware is usually an opaque
blob, we don't have that luxury. So it really isn't that much of an
issue to have the firmware in the firmware/ directory where we've been
putting it.

When you have a new firmware blob and you want to update it, it really
is no harder this way than it was before. In fact, in most cases I've
converted so far, it should be easier. That's certainly the intention.

> I like the goal, but see little effort in the area of "make this 
> transition painless for users."

Actually this choice was made with that as the primary motivation. It
makes it easy for 'make firmware_install' to do the right thing, and
that should be the primary interface for the user. It also makes it
simple to build a 'shadow' git tree, like the kernel-headers tree, which
contains _only_ the firmware -- and also to build a GPL-only kernel
source tarball which _omits_ it, for whose who want such a thing (like
Fedora does).

If you look at my original patches, you'll see that I did _start_ by
putting firmware blobs in the source tree next to the drivers, using hex
arrays in C code with DECLARE_BUILTIN_FIRMWARE(). I revised that
approach when I saw it was better to put them in firmware/ and implement
'make firmware_install' instead. And I stand by that decision.

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