Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1477827

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

From Bjorn Andersson <bjorn.andersson@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC] fs: add userspace critical mounts event support
Date 2016-09-06 23:20 +0200
Message-ID <sevWF-7jG-3@gated-at.bofh.it> (permalink)
References (5 earlier) <sd6xk-63g-11@gated-at.bofh.it> <sd70m-6u6-5@gated-at.bofh.it> <sdaAV-oe-5@gated-at.bofh.it> <sesFs-52m-33@gated-at.bofh.it> <setrQ-5CI-35@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote:

> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> <bjorn.andersson@linaro.org> 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
> and module together" question.
> 

The answer to this depends on the details of the suggestion; but
generally there's a much stronger bond between the kernel and the driver
than between the driver and the firmware in my cases.

E.g. we have a single remoteproc driver loading and controlling the
Hexagon DSP found in several Qualcomm platforms, so a single kernel
binary could (practically) load hundreds of variants of the firmware.

Both the kernel binary and the firmware in this example are side-loaded
onto the device during development - independently of each other, as
they are developed by different teams (or maybe even different
companies).

I assume that you're not suggesting to actually tie the module together,
as that would be practically difficult and a waste of resources.

Which leaves us with the suggestion that we should store the kernel
module with the firmware file, which is just infeasible from a few
practical reasons - again mostly related to the development flow and how
the files are contained on the devices.

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

In several cases we have a single remoteproc driver controlling several
different co-processors. Further more with the aspiration of being able
to run the same kernel binary (including modules) on more than one
product this is simply not feasible.

As I said above, beyond development there are hundreds of variants of
these firmware files in products - each weighting in at 10-50MB.

The firmware loading part (remoteproc) doesn't care about these
differences and the functional drivers attaching to the services
provided by the firmware can handle the differences between them.

> The hack is a hack, and it just sounds *stupid*.
> 

This I totally agree with.

Regards,
Bjorn

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe Daniel Vetter <daniel.vetter@ffwll.ch> - 2016-08-25 13:10 +0200
  Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-25 21:50 +0200
    Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe Daniel Vetter <daniel.vetter@ffwll.ch> - 2016-08-25 22:20 +0200
      Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-25 22:30 +0200
    Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-08-25 22:40 +0200
    Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on  init or probe "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-03 02:00 +0200
      [RFC] fs: add userspace critical mounts event support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-03 02:30 +0200
        Re: [RFC] fs: add userspace critical mounts event support Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-03 06:20 +0200
          Re: [RFC] fs: add userspace critical mounts event support Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-09-03 06:30 +0200
            Re: [RFC] fs: add userspace critical mounts event support Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-09-03 20:00 +0200
              Re: [RFC] fs: add userspace critical mounts event support Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-09-03 20:20 +0200
                Re: [RFC] fs: add userspace critical mounts event support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-07 00:00 +0200
                Re: [RFC] fs: add userspace critical mounts event support Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-09-07 00:30 +0200
                Re: [RFC] fs: add userspace critical mounts event support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-07 01:20 +0200
              Re: [RFC] fs: add userspace critical mounts event support Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-03 20:30 +0200
          Re: [RFC] fs: add userspace critical mounts event support Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-09-06 19:50 +0200
            Re: [RFC] fs: add userspace critical mounts event support Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-06 20:40 +0200
              Re: [RFC] fs: add userspace critical mounts event support Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-09-06 23:20 +0200
                Re: [RFC] fs: add userspace critical mounts event support Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-07 00:00 +0200
                Re: [RFC] fs: add userspace critical mounts event support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-07 01:10 +0200
              Re: [RFC] fs: add userspace critical mounts event support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-09-07 00:40 +0200

csiph-web