Re: [RFC] fs: add userspace critical mounts event support
On 06/09/2016 16:04, Luis R. Rodriguez wrote: > They claim that without it there is the race between /lib/firmware > being ready and driver asking for the firmware. Hope it's understood by now. > I was told there were quite a bit of out-of-tree hacks to address > this without using the usermode helper, There are: https://chromium-review.googlesource.com/#/c/354089/ wait until SYSTEM_RUNNING before loading DMC firmware. > the goal of this patch was to create the discussion needed to a > proper resolution to this. Sincere thanks. >>> On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: >>> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson 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. Indeed. The i915 DMC firmware is an interesting example. First of all it’s _optional_! It’s critical for battery-powered systems but the i915 driver works without it. Dan wrote: > Plus all gpu drivers which need firmware. And yes we must load them > at probe because people are generally pissed when they boot their > machine and the screen goes black. On top of that a lot of people > want their gpu drivers to be built-in, but can't ship the firmware > blobs in the kernel image because gpl. Yep, there's a bit a > contradiction there ... Eppur si muove: 1) As Dan just wrote, users expect the screen to light up as soon as they press the power button so the i915 driver is built-in 2) ... yet they’ll never notice the nanojoules of battery loss caused by the DMC firmware being on a filesystem and loaded a tiny bit later. SoCs and platforms have become some new kind of distributed systems where other processors run their own, specific software/OS/firmware. >From this perspective the kernel plays a role similar to a boot server; and choke point. Granted: booting various and heterogeneous distributed systems doesn’t look like a simple problem to solve generically. Yet at the moment the kernel doesn’t help by not even supporting something as basic as being told when the files it’s (unfortunately) in charge to deploy to other nodes become available and ready to deploy. It can’t be assumed that the driver and the firmware are two parts of the same software piece whereas they actually run on two different processors, are most likely developed and validated by completely different teams and released on different lifecycles. Especially in the Linux case. I hope this distributed systems analogy captures the essence of the examples and rationales detailed elsewhere in this thread.
Re: [RFC] fs: add userspace critical mounts event support
On 06/09/2016 16:04, Luis R. Rodriguez wrote: > They claim that without it there is the race between /lib/firmware > being ready and driver asking for the firmware. Hope it's understood by now. > I was told there were quite a bit of out-of-tree hacks to address > this without using the usermode helper, There are: https://chromium-review.googlesource.com/#/c/354089/ wait until SYSTEM_RUNNING before loading DMC firmware. > the goal of this patch was to create the discussion needed to a > proper resolution to this. Sincere thanks. >>> On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: >>> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson 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. Indeed. The i915 DMC firmware is an interesting example. First of all it’s _optional_! It’s critical for battery-powered systems but the i915 driver works without it. Dan wrote: > Plus all gpu drivers which need firmware. And yes we must load them > at probe because people are generally pissed when they boot their > machine and the screen goes black. On top of that a lot of people > want their gpu drivers to be built-in, but can't ship the firmware > blobs in the kernel image because gpl. Yep, there's a bit a > contradiction there ... Eppur si muove: 1) As Dan just wrote, users expect the screen to light up as soon as they press the power button so the i915 driver is built-in 2) ... yet they’ll never notice the nanojoules of battery loss caused by the DMC firmware being on a filesystem and loaded a tiny bit later. SoCs and platforms have become some new kind of distributed systems where other processors run their own, specific software/OS/firmware. >From this perspective the kernel plays a role similar to a boot server; and choke point. Granted: booting various and heterogeneous distributed systems doesn’t look like a simple problem to solve generically. Yet at the moment the kernel doesn’t help by not even supporting something as basic as being told when the files it’s (unfortunately) in charge to deploy to other nodes become available and ready to deploy. It can’t be assumed that the driver and the firmware are two parts of the same software piece whereas they actually run on two different processors, are most likely developed and validated by completely different teams and released on different lifecycles. Especially in the Linux case. I hope this distributed systems analogy captures the essence of the examples and rationales detailed elsewhere in this thread.
Re: [RFC] fs: add userspace critical mounts event support
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. Could this one fly?
Re: [RFC] fs: add userspace critical mounts event support
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. Could this one fly?
