Re: [RFC] fs: add userspace critical mounts event support
From: Bjorn Andersson <hidden>
Date: 2016-09-06 21:11:27
Also in:
linux-serial, lkml
On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote:
On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson [off-list ref] wrote:quoted
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