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]

Message-Id: <200809111832.38051.elendil@planet.nl>
Date:	Thu, 11 Sep 2008 18:32:36 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Woodhouse <dwmw2@...radead.org>, davem@...emloft.net,
	jeffm@...e.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

On Thursday 11 September 2008, Linus Torvalds wrote:
> On Thu, 11 Sep 2008, Frans Pop wrote:
> > Just keep on ignoring current issues.
>
> Aren't _you_ the one who are ignoring current issues?

I don't think so.
_The_ current issue for me is that I can no longer build Debian kernel 
packages using 'make deb-pkg', which is part of _your_ tree, and install 
the resulting package *NOW*.

> The fact is, _currently_ everybody looks in /lib/firmware. The fact is,
> most people don't want millions of copies of the firmware (one copy for
> each kernel they compile - think about those of us who compile kernels
> every day).

Right, I totally agree. I did about 40 kernel builds the past two days.
(Yes, I know, there are people doing way more builds than that.)
I regularly have 5 kernels installed simultaneously, and sometimes more if 
I'm actively trying to trace an issue.

> I actually like a release-specific firmware directory, but I think it's
> the *vendor* kernel that should do it, not the normal kernel. The
> _vendor_ should put its firmware files in some vendor-specific place,
> and then add that to the end of the firmware loading path.

Hey, I'm NOT propagating versioned dirs in this thread! I've only 
mentioned them as one of the two options and explained why I think it's a 
valid choice in some scenario's.
I've also explained that I don't think Debian will go that way, but that 
is irrelevant. I basically don't care what Debian does for its official 
packages.

> So all of the noise in this whole discussion has been totally inane and
> idiotic.

Please explain what is idiotic about mentioning that 'make deb-pkg' 
produces broken packages solely because of the separate firmware and that 
that is *not* something that is easily solvable because of the way 
package management works?
Please explain why it is idiotic to say that having a compatibility option 
that would allow me to build firmware _inside_ modules, just like we 
always used to, would solve that problem?

That has nothing to do with vendors or distros. It has to do with me (and 
others like me, as a kernel tester, having to live with broken tools NOW.

I like 'make dep-pkg' because it very quickly produces a solid, *single* 
Debian package I can install and use for kernel testing. I'd like to keep 
using that as I have been, but the separation of firmware essentially 
kills my current workflow.
--
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/