Re: [RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

On Tue, Sep 06, 2016 at 11:32:05AM -0700, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> <bjorn.andersson@xxxxxxxxxx> wrote:
> >
> > Linus, I reversed the order of your questions/answers to fit my answer
> > better.
> 
> Nobody has actually answered the "why don't we just tie the firmware

This is not about firmware anymore. The fact that we were reading files from
the filesystem in different ways called for a generic API, that was done by
Mimi with the new generic kernel_read_file_from_path(), the fact that there
were race concerns with firmware means such races are also in theory possible
outside of firmware.

> and module together" question.

In terms of the firmware, licensing is one reason I'm aware of. Another reason
is updates to firmware files may not implicate a driver update -- its pointless
to rebuild a kernel if all you need is a firmware update.

For both modules and built-in we already have the option to bundle firmware
into initramfs, and CONFIG_EXTRA_FIRMWARE, some folks do not want to use these.
Bjorn noted a few reasons why. Here's the full list of reasons I've heard why
folks shy away from these:

  o Licensing
  o You still want the ability to do updates
  o The size of the files can be huge (remoteproc is talking about 10 MiB files)

Do we want to bring the firmware closer together than what we allow for modules? If
so it may make sense to use a modpost command to try to bundle module and
firmware together, the build system could use the MODULE_FIRMWARE() for that.
It does mean you now have a build dependency for linux-firmware on the kernel.
Do we want that?

> Really. If the driver doesn't work without the firmware, then why the
> hell is it separated from it in the first place?

This I agree with, although you still have to consider you may want to enable
updates for firmware without a driver update.

  Luis