On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc [off-list ref] wro=
te:

On 03/09/2016 11:10, Dmitry Torokhov wrote:

quoted

I was thinking if we kernel could post
"conditions" (maybe simple stings) that it waits for, and userspace
could unlock these "conditions". One of them might be "firmware
available".

On idea offered by Josh Triplett that seems to overlap with this one
is to have something similar to the (deprecated) userhelper with
*per-blob* requests and notifications except for one major difference:
userspace would not anymore be in charge of *providing* the blob but
would instead only *signal* when a given blob becomes available and is
either found or found missing. Then the kernel loads the blob _by
itself_; unlike the userhelper. No new =E2=80=9Ccritical filesystem=E2=80=

=9D concept

and a *per-blob basis*, allowing any variation of blob locations
across any number of initramfs and filesystems.

Really, I do not quite understand why people have issues with usermode
helper/uevents. It used to work reasonably well (if you were using
request_firmware_nowait()), as the kernel would post the request and
then, when userspace was ready[^Hier], uevents would be processed and
firmware would be loaded. We had a timeout of 60(?) seconds by
default, but that would be adjusted as systems needed.

Unfortunately it all broke when udev started insisting [1] on
servicing some uevents in strict sequence, which resulted in boot
stalls. Maybe the ultimate answer is to write a firmware loading
daemon that would also listen to netlink events and do properly what
udev refused to be doing? The distribution would know when it is ready
to service firmware requests (and thus when to start this daemon), and
we would have the freedom of having drivers both built-in and as
modules and bulding firmware into kernel, intiramfs or keep on a
"real" fs available at later time.

Thanks.

--=20
Dmitry

[1] https://lwn.net/Articles/518942/