[systemd-devel] udev firmware loading

[Kay Sievers]

On Wed, Nov 27, 2013 at 12:53 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Kay Sievers [2013-11-27 12:47 +0100]:
>> All of that is gone and will not come back, udev has no idea about
>> device firmware and does no longer want to know about it. There is no
>> way to tell these days what firmware was requested or loaded, it's all
>> happening in the kernel only.
>>
>> Unless we want to invent a mechanism to queue up/log that information
>> in the kernel and communicate that to userspace, you can just delete
>> all the code that handles this in userspace.
>
> Too bad, as all this has already worked in the past. There used to be
> a "firmware" subsystem uevent for firmware loading, that should at
> least be generated if the kernel cannot load the firmware by itself?

No, it shouldn't. The firmware uevents/class was a big mistake, and a
broken concept. It is wrong to create fake devices inside the kernel
just to establish a conceptually broken sunc transaction to userspace
which might lock until a timeout.

Also many driver authors were not be able to handle the concept of
async requests, and their stuff was just too broken for the reality of
the complex udev firmware fake device requester.

> udev itself doesn't need to know about it any more than it needs to
> know what to do about a new block device, but one could then continue
> to attach services like PackageKit in userspace which can map a
> requested firmware to a package to install.

No, udev has no business really in loading firmware, or to carry out
any such information.

> This used to be a way to make more exotic hardware (like DVB-T sticks
> or the dreaded Broadcom wifis) "just work".

There was a lot more not working with the broken idea of a
fake-device-firmware-requester, than it ever made working. It should
never come back, just go away. :)

There are tons of drivers which request like 5 file names in a row and
use the on they find, leaving names requested which are not expected
to exists, but all works fine.

There is a lot of hardware which just checks if there is a newer
firmware, but there will never be.

Then there is microcode updates using the firmware loader, requesting
stuff which almost never exist.

If we want/need that information back, it needs to be a new facility, and
udev will not be involved. But I don't see how useful such info would be,
there are a lot of requests today which are fine to never get answered,
and which should not trigger any userspace reaction to it.

Kay