Re: [PATCH] firmware: wake all waiters

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 12:52 PM, Bjorn Andersson
<bjorn.andersson@xxxxxxxxxx> wrote:
> On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote:
>> On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote:
>> > Are you saying that each kernel driver should be written so that it will
>> > either do direct loading or use firmwared?
>>
>> Hell No! You can fork firmwared or use whatever the hell bin-foo you want.
>> Even if its proprietary and glued with evil rainbow unicorns on it.  The dual
>> mode, best-effort mode and final-mode devices it implemented are key to what
>> you want to mimic as an example to achieve the goal in question.
>>
>
> I'm sorry but your language is totally inappropriate and the reason why
> I tend to stay away from firmware-related discussions.

I'm sorry if I offended you, the goal here was to use an exaggerated
example of what anyone could use to draw in firmware into the kernel.

>> Please give that thought / architecture solution a spin and let me know if
>> it suffices for your needs.
>>
>
> Which solution do you refer to here?

The model of a best-effort and final-mode.

> But as I said, in my view, the decision of making the kernel depend on a
> user space firmware loading mechanism or direct loading should be that
> of the system designer - not the kernel.

You get that freedom today. The fallback mechanism *allows* files to
be fetched in whatever way possible, by issuing a uevent, its up to
userspace to figure out how to gather that and toss it back into the
kernel using the sysfs interface. The firemward daemon is nothing but
an example *new* daemon which uses a model to address the rootfs /
pivot root dilema, as only userspace can know when userspace *is
ready*.

So its not clear to me yet what your grudge with using firmwared with
this new model is exactly. Are you saying you want to *require* the
fallback mechanism from the start, so just skipping the direct FS
lookup ? That would be a new feature request, and we can certainly
consider it, but I'll need Greg to clue me in first on how he'd prefer
an API evolution for new features.

 Luis