On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc <marc.herbert@xxxxxxxxx> wrote: > 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. > Really, I do not quite understand why people have issues with usermode helper/uevents. It used to work reasonably well (if you were using request_firmware_nowait()), as the kernel would post the request and then, when userspace was ready[^Hier], uevents would be processed and firmware would be loaded. We had a timeout of 60(?) seconds by default, but that would be adjusted as systems needed. Unfortunately it all broke when udev started insisting [1] on servicing some uevents in strict sequence, which resulted in boot stalls. Maybe the ultimate answer is to write a firmware loading daemon that would also listen to netlink events and do properly what udev refused to be doing? The distribution would know when it is ready to service firmware requests (and thus when to start this daemon), and we would have the freedom of having drivers both built-in and as modules and bulding firmware into kernel, intiramfs or keep on a "real" fs available at later time. Thanks. -- Dmitry [1] https://lwn.net/Articles/518942/ -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
