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: <BANLkTinTUdAgF4eQ8_JtWgT_jJB5f7nT-A@mail.gmail.com>
Date:	Mon, 2 May 2011 14:40:33 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: linux-firmware tree

On Mon, May 2, 2011 at 12:38 PM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Mon, 2011-05-02 at 19:57 +0100, Mike Waychison wrote:
>> Hi David,
>>
>> I'm trying to understand the purpose of the linux-firmware tree.
>> Forgive me if this is a stupid question, but the only information
>> about it I could find was your original post back in 2008:
>> https://lwn.net/Articles/294308/
>>
>> Will the Linux kernel sources always continue to have the firmware
>> blobs and the linux-firmware tree is only for those users of distros
>> that strip the firmware out?
>
> No, the legacy firmware images from the kernel tree are going to be
> removed. They were only kept for backward compatibility.
>
> The linux-firmware tree has a lot of things that were never included in
> the kernel source; no *new* firmware images are being (or at least
> should be) added to the kernel source itself.
>
> Everyone should be using the linux-firmware tree by now.

Fair enough.  We haven't actually hit a case where the firmware
required by any of the drivers we use isn't already present in the
tree.

I'm trying to figure out how we could ship firmware blobs on our
systems going forward.  Currently, we let firmware get installed to
our install root via the modules_install target, and then package up
the install root.  If drivers are going to request firmware blobs from
userland without them being picked up in-tree by
fw-shipped-$(CONFIG_FOO), we'll need to know at build time which
firmware blobs to package up.

I don't see anything in the build (looking at scripts/Makefile.fwinst
in particular) that allows the build to enumerate out-of-tree firmware
files required by drivers.  Do you have any thoughts on how this could
be enumerated? (if it isn't already?)


The alternative would be to ship the whole of the linux-firmware tree
on every machine we have, but that seems like a bad idea as it is only
going to grow with time and we don't have the MiB budget for such a
thing.
--
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