[RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

On Wed, Nov 9, 2016 at 3:21 AM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
> <daniel.wagner at bmw-carit.de> wrote:
>> [CC: added Harald]
>>
>> As Harald pointed out over a beer yesterday evening, there is at least
>> one more reason why UMH isn't obsolete. The ordering of the firmware loading
>> might be of important. Say you want to greet the user with a splash screen
>> really early on, the graphic card firmware should be loaded first. Also the
>> automotive world has this fancy requirement that rear camera must be on the
>> screen within 2 seconds. So controlling the firmware loading order is of
>> importance (e.g. also do not overcommit the I/O bandwith not so important
>> firmwares). A user space helper is able to prioritize the request
>> accordingly the use case.
>
> That seems like a valid problem, but I don't think that UMH adequately
> solves it.  Sure, loading firmware in the right order avoids a >2sec
> delay due to firmware loading, but what happens when you have a slow
> USB device that *doesn't* need firmware plugged in to your car's shiny
> USB port when you start the car?
>
> It seems to me that this use case requires explicit control over
> device probing and, if that gets added, you get your firmware ordering
> for free (just probe the important devices first).

Agreed, we could prioritize requests but actually these days we don't
queue requests we simply go through them serially. We could add later
a priority aspect for async requests but its not clear this is needed
yet.

As Andy notes most of these requirements could be solved through
alternative means. One is loading your module really early so stuffing
it into for instance initramfs and if using systmed for instance
listing it on a say /etc/modules-load.d/load.conf file, otherwise
priority of loading the module is set through the actual default init
level associated for the module, if using module_init() that's just
device_initcall() and these are all probed serially. If your driver is
built-in and needs to be after rootfs_initcall() we don't provide
finer granularity for ordering other than just device_initcall() and
late_initcall(). In the future we could extend this easily but I
really do want a valid use case which we can't handle with today's
infrastructure. If this is a special driver and we are certain it must
load really early and first than others for *all* system cases when
the driver is needed, it may be worth looking into this as a new
category. If so let me know and I think we can work on a solution. If
you have systemd though I think using something like
/etc/modules-load.d/load.conf should suffice.

  Luis