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 10:58:41 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Marcel Holtmann <holtmann@...ux.intel.com>
Cc:	davem@...emloft.net, dwmw2@...radead.org, jeffm@...e.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

Marcel Holtmann wrote:
> it is that the Debian maintainer screwed this up.

WRONG! NOT TRUE! FUD!
The Debian maintainer has done nothing of the kind.

> To shed some light into the problem with Debian/Ubuntu. They install the
> firmware in /lib/firmware/`uname -r`/

Debian does no such thing! It may be that Ubuntu does this, but that does 
NOT mean that Debian does too.

Feel free to examine any of the packages here and check where they install 
their firmware files:
http://packages.debian.org/search?suite=sid&searchon=names&keywords=firmware

Examples:
http://packages.debian.org/sid/all/firmware-qlogic/filelist
http://packages.debian.org/sid/all/firmware-bnx2/filelist

> Problem comes when installing let say 2.6.27 since then the firmware
> will be looked up in /lib/firmware/ and /lib/firmware/2.6.27/ and
> actually it will not be found. Since it is in /lib/firmware/2.6.26-xx/
> or something similar.
> 
> So having the kernel install everything in /lib/firmware works just fine
> with every distro. However looking for firmware that is not shipped with
> the kernel, we have a problem since Debian/Ubuntu just not installs it
> in the right directory. And there is nothing the kernel can do about it
> since it will not touch firmware it doesn't ship. The distro has to fix
> their firmware or the users have to place a copy in /lib/firmware/ where
> it actually should have been in the first place.

This is a ridiculously simplified view of the issue. Why can't you at 
least acknowledge that people were faced with a real problem _without_ 
proper guidance, support or transition path from their upstream source 
and made their best effort to solve that issue.

Note that this thread was started by someone from Suse, not Debian or 
Ubuntu.

Cheers,
FJP
--
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/