linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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: <1216150769.27242.81.camel@violet.holtmann.net>
Date:	Tue, 15 Jul 2008 21:39:29 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Frans Pop <elendil@...net.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	jeff@...zik.org, arjan@...radead.org, akpm@...ux-foundation.org,
	dwmw2@...radead.org, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from
	in-kernel, use it in more drivers.

Hi Henrique,

> > You release 2.6.27-rc2 and I build it. Ouch! It fails to install, at least 
> > if I want to install it _alongside_ 2.6.27-rc1 or other kernels (which I 
> > do!). Why does it fail? Because dpkg's package management does not allow 
> > one package to overwrite files already "owned" by another package.
> 
> I believe I read in the previous thread that some distros are already using
> /lib/firmware/<kernel version>/.
> 
> There was also the suggestion of moving the entire set of kernel-packaged
> firmware to /lib/modules/<kernel version>/firmware, probably while keeping
> /lib/firmware as a second place to look for firmware so that we don't hose
> any system.

can we please leave the /lib/modules/*/firmware idea out of it. While
this thread is about the kernel drivers that need firmware loading, but
it is not the whole story. We do have hardware that needs a firmware
loading process that takes place entirely in userspace. In some USB and
UART cases we can do the firmware loading step before any kernel driver
takes control of that device and currently these firmware loading
helpers look into /lib/firmware/ where every firmware file should be
placed.

Also the /lib/firmware directory was chosen a long time ago and you find
the discussion on the linux-hotplug mailing list archive if you are
interested.

That said, using /lib/firmware/`uname -r`/ like Ubuntu supports right
now and then fall back to /lib/firmware looks like a sane approach to
me. However as David mentioned, this needs patches to udev first before
we go any step further.

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/