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: <200809111058.42362.elendil@planet.nl>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ