linux-kernel - Re: [PATCH] firmware: Allow release-specific firmware dir

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:	Thu, 11 Sep 2008 07:50:27 -0700
From:	David Woodhouse <dwmw2@...radead.org>
To:	Frans Pop <elendil@...net.nl>
Cc:	davem@...emloft.net, jeffm@...e.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

On Thu, 2008-09-11 at 11:52 +0200, Frans Pop wrote:
> Solution 2:
(separate firmware package)

This is what we're doing in Fedora, and what I think makes most sense.

At the moment, Fedora's package is still taken from the kernel source --
but fairly shortly, we'll move to building it from the linux-firmware
repository on kernel.org. That repository contains everything that's in
the kernel tree, and more -- now that we have it completely separate,
more companies are willing to allow us to include their firmware. We've
already rounded up some which were previously separate, and we'll
shortly be adding more firmware files which weren't previously available
to Linux users at all, except by copying it from the Windows installer.

> a) naturally allows firmware to be split between "free" and "non-free"

Indeed. So it allows the 'free software or nothing' nutters to have
their own replacement firmware package with none of the nasty stuff they
don't like.

> b) places a burden on the end-user to install/upgrade the firmware he
>    needs separately from the kernel

Not really. The new kernel package can just require the firmware
package. There's not really much of a burden on the end-user, is there?

> c) makes system installation more complex as the right additional firmware
>    package(s) need to be retrieved and installed

It's a simple dependency, handled just like dependencies normally are --
it's not exactly a giant leap in complexity.

> d) will break installed systems on upgrades (unless special measures are
>    taken): users may need to install additional firmware packages on a
>    kernel upgrade to keep a driver working

I have yet to see reports of it breaking Fedora. You upgrade the kernel,
the firmware package is automatically installed to satisfy the
dependency. And it just works.

Really, people seem to be imagining problems where they don't exist. I
don't want to just dismiss real problems -- but I don't _see_ real
problems either. Just people like Dave screaming "you broke it for real
users, like Herbert"... and Herbert saying "er, no you didn't really."
So I have to take it with a pinch of salt.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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