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 18:16:37 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	Frans Pop <elendil@...net.nl>
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

Hi Frans,

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

I apologize for this. You are absolute right. Debian does the correct
thing and only Ubuntu made this a problem.

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

That is just plain naive on the package maintainer side. If the package
maintainer has to solve problems, then contacting upstream should be the
first thing to do. I might be wrong here, but I don't recall any
requests like this on LKML or linux-hotplug. They just did it their way
without contacting either kernel guys or udev people.

Regards

Marcel


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