On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:

On 16-12-2016 11:40, Pali Rohár wrote:

quoted

On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:

quoted

On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:

quoted

For the new API a solution for "fallback mechanisms" should be
clean though and I am looking to stay as far as possible from the
existing mess. A solution to help both the old API and new API is
possible for the "fallback mechanism" though -- but for that I
can only refer you at this point to some of Daniel Wagner and
Tom Gunderson's firmwared deamon prospect. It should help pave
the way for a clean solution and help address other stupid
issues.

The firmwared project is hosted here

https://github.com/teg/firmwared

As Luis pointed out, firmwared relies on
FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.

I know. But it does not mean that I cannot enable this option at
kernel compile time.

Bigger problem is that currently request_firmware() first try to
load firmware directly from VFS and after that (if fails) fallback
to user helper.

So I would need to extend kernel firmware code with new function
(or flag) to not use VFS and try only user mode helper.

Why do you need the user-mode helper anyway. This is all static data,
right?

Those are static data, but device specific!

So why not cook up a firmware file in user-space once and put
it in /lib/firmware for the driver to request directly.

1. Violates FHS

2. Does not work for readonly /, readonly /lib, readonly /lib/firmware

3. Backup & restore of rootfs between same devices does not work (as 
rootfs now contains device specific data).

4. Sharing one rootfs (either via nfs or other technology) does not work 
for more devices (even in state when rootfs is used only by one device 
at one time).

And it is common that N900 developers have rootfs in laptop and via usb 
(cdc_ether) exports it over nfs to N900 device and boot system. It 
basically break booting from one nfs-exported rootfs, as that export 
become model specific...

Seems a bit
overkill to have a {e,}udev or whatever daemon running if the result
is always the same. Just my 2 cents.

No it is not. It will break couple of other things in Linux and device 
and model specific calibration data should not be in /lib/firmware! That 
directory is used for firmware files, not calibration.

-- 
Pali Rohár
pali.rohar@gmail.com