[RFC] fs: add userspace critical mounts event support

[Dmitry Torokhov]

On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc <marc.herbert at intel.com> wrote:
> On 03/09/2016 11:10, Dmitry Torokhov wrote:
>> 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 “critical filesystem” 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.

-- 
Dmitry

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