Discussion:
[PATCH] firmware: wake all waiters
(too old to reply)
Luis R. Rodriguez
2017-06-27 22:24:19 UTC
Permalink
Raw Message
The problem is that advanced NICs are quite programmable [1] and
depending on use case one may want to load different firmware files.
Right, so in the 802.11 world some devices might use different firmware for
different modes of operation, STA, AP, Mesh, but this is all very protocol
specific, so userspace could tickle the kernel about a mode.
Do your use cases have protocol definitions which can be exposed in userspace?
Or are these just fw variants with different bells and whistles? How man
different use cases are we talking about?
Right now we have three modes that come from Netronome itself, a "basic
NIC" one, and two advanced for TC flower/Open vSwitch acceleration and
for eBPF offload. I was hoping some enumeration scheme could work here,
but I really can't come up with one.
How about just supporting 3 firmware names, with the first two being optional,
but if found one of those two is found it would use that one. Then only if
both of these are not present would a default be looked for and used?

In terms of interface, a simple symlink / renaming scheme would suffice to
support this. No custom hooks at all.
To be honest waiting for rootfs to be available is lower on my list of
priorities, but it's definitely nice to have. I also don't care about
supporting more complex rootfs setups, simply trying whatever comes
after initramfs covers 99.9% use cases. 0.1% can load the FW manually/
rebind the driver IMHO.
Right, the only issue with firmwared is you'd expect folks would have
it deployed, and that's not the case today, but when you do control the
ecosystem you can certainly use it as an option. Let me know if you
do try it out.
Be careful how you do this as you'll have to support it in the driver forever
if you use something like sysfs I think, otherwise you will break some
userspace. However if you use debugfs I think its understood that's loose API.
Unfortunately the netdev community does not like debugfs. I would
prefer to extend the firmware subsystem if possible and use the
existing sysfs interface, just in a new "mode".
I don't think this is required, you can simply use different filenames as
noted above.
Current firmware subsystem doesn't seem to cater to this use case to
well.
Its a matter of asking and talking. I've provided references of things to
try to address the hacky -EPROBE_DEFER. It does however require a userspace
daemon used, so it does require use of the uevent fallback mechanism.
Do you know how systemd developers feel about the issue (CCed)? Given
that it seems to dominate in data center OSes now I'm slightly worried
having to push Big Linux Vendors to package some seemingly
embedded-centric software just to make advanced NICs run :(
firmwared was written by a systemd developer :)

I think it was first packaged into systemd, and then it was split out to
help those who want it external.
- how to make sure different cards, which request the same file name
can be served different default firmwares...
I believe your patch + the error path fix will handle this now, no?
I'm not sure. I think it would work if I set FW_OPT_NOCACHE, though.
I need to test that.
Why do you need FW_OPT_NOCACHE?

Luis
Lennart Poettering
2017-06-28 07:06:14 UTC
Permalink
Raw Message
Post by Luis R. Rodriguez
Do you know how systemd developers feel about the issue (CCed)? Given
that it seems to dominate in data center OSes now I'm slightly worried
having to push Big Linux Vendors to package some seemingly
embedded-centric software just to make advanced NICs run :(
firmwared was written by a systemd developer :)
No it wasn't. I don't know what firmwared is really. Sorry.
Post by Luis R. Rodriguez
I think it was first packaged into systemd, and then it was split out to
help those who want it external.
Certainly not. I'd sure know about that. ;-)

Lennart
--
Lennart Poettering, Red Hat
Luis R. Rodriguez
2017-06-28 16:06:10 UTC
Permalink
Raw Message
On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
Post by Lennart Poettering
Post by Luis R. Rodriguez
Do you know how systemd developers feel about the issue (CCed)? Given
that it seems to dominate in data center OSes now I'm slightly worried
having to push Big Linux Vendors to package some seemingly
embedded-centric software just to make advanced NICs run :(
firmwared was written by a systemd developer :)
No it wasn't. I don't know what firmwared is really. Sorry.
Is Tom Gundersen not a systemd developer?
Post by Lennart Poettering
Post by Luis R. Rodriguez
I think it was first packaged into systemd, and then it was split out to
help those who want it external.
Certainly not. I'd sure know about that. ;-)
Sorry I may have confused 'intended to be at first'. Tom and Daniel
can elaborate.

Luis
Lennart Poettering
2017-06-28 16:21:09 UTC
Permalink
Raw Message
Post by Luis R. Rodriguez
On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
Post by Lennart Poettering
Post by Luis R. Rodriguez
Do you know how systemd developers feel about the issue (CCed)? Given
that it seems to dominate in data center OSes now I'm slightly worried
having to push Big Linux Vendors to package some seemingly
embedded-centric software just to make advanced NICs run :(
firmwared was written by a systemd developer :)
No it wasn't. I don't know what firmwared is really. Sorry.
Is Tom Gundersen not a systemd developer?
Not really anymore, and "firmwared" is an effort independent of
systemd, never was part of it, and while I heard Tom was working on
this I was not aware of the project's naming or anything else...

Lennart
--
Lennart Poettering, Red Hat
Luis R. Rodriguez
2017-06-28 17:57:47 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Luis R. Rodriguez
On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
Post by Lennart Poettering
Post by Luis R. Rodriguez
Do you know how systemd developers feel about the issue (CCed)? Given
that it seems to dominate in data center OSes now I'm slightly worried
having to push Big Linux Vendors to package some seemingly
embedded-centric software just to make advanced NICs run :(
firmwared was written by a systemd developer :)
No it wasn't. I don't know what firmwared is really. Sorry.
Is Tom Gundersen not a systemd developer?
Not really anymore, and "firmwared" is an effort independent of
systemd, never was part of it, and while I heard Tom was working on
this I was not aware of the project's naming or anything else...
Alright, thanks for the clarifications and sorry for the confusion!

In that case firmwared remains *just* an architecture example of an alternative
to the problem of looking for firmware through a *fallback mechanism* and
addressing "is my real rootfs mounted yet" problem some folks have struggled to
resolve, "are we sure we're ready to look for all firmware?".

Lennart, if you have a better architectural suggestion let us know.

I realize that the firmware fallback mechanism was ripped out of systemd long
ago, specifically as of systemd commit be2ea723b1d0 (“udev: remove userspace
firmware loading support”) as of v217 on August, 2014. This means most Linux
distributions today are not using or taking advantage of the firmware fallback
mechanism provided by kobject uevents.

This is specially exacerbated due to the fact that most distributions today
disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK which *means* only the custom
fallback mechanism (no uevents are issued) can be used on those distributions,
and we actually want to *avoid* having more drivers use that mechanism. Only
2 drivers remain upstream now which explicitly require the custom fallback
mechanism. We don't to add any more.

This leaves distributions that want a fallback mechanism today only with the
option to enable CONFIG_FW_LOADER_USER_HELPER_FALLBACK and rely on uevents, and
firmwared was an architectural example of how to address the rootfs problem.

Android is enabling CONFIG_FW_LOADER_USER_HELPER_FALLBACK these days it seems.

If it helps the fallback mechanism is now documented here:

https://www.kernel.org/doc/html/latest/driver-api/firmware/fallback-mechanisms.html

The concept of firmwared was simple: it had best-effort mode and final-mode.
It relies on CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y and relies on uevents.
You boot with it on best-effort mode where firmware is hunted for in a best
effort way, but it does not fail a load through the kernel's sysfs interface
used for the fallback mechanism. Then once userspace knows we have reached the
real rootfs (since only it knows when this happens) it kicks firmwared into
final-mode, which in turn can now iterate over pending firmware and send a "not
found" with certainty.

So the focus for now is ironing out something that we know works *very well*
for the CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y folks.

It'd be great if we had a solution that could work for
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n folks but its unclear if that's
possible, so it may be best to only revisit this if and when we know for sure
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y and the rootfs issue is properly ironed
out with the uevents fallback mechanism.

Luis
Daniel Wagner
2017-06-29 19:56:29 UTC
Permalink
Raw Message
Post by Luis R. Rodriguez
On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
Post by Lennart Poettering
Post by Luis R. Rodriguez
I think it was first packaged into systemd, and then it was split out to
help those who want it external.
Certainly not. I'd sure know about that. ;-)
Sorry I may have confused 'intended to be at first'. Tom and Daniel
can elaborate.
Tom helped out building the daemon as standalone project. There is no
real reason that it needs to be part of the systemd code base.

Thanks,
Daniel

Loading...