0bd8c74cc0
A race condition is hypothesized in the following scenario: 1. User starts up the system and fwupd doesn't start automatically. 2. User manually calls fwupdmgr install blah.cab (or fwupdmgr update really) which uses dbus activation to start fwupd systemd unit. 3. This runs coldplug on thunderbolt plugin, no devices found. Thunderbolt power runs coldplug routine. a. This sets forcepower with a timeout to turn off after 20 seconds. b. Coldplug exits. 4. update routine starts a. Thunderbolt plugin starts flash routine. b. Thunderbolt power plugin turns off force power in middle of flash routine. c. Issue described happens. |
||
|---|---|---|
| .. | ||
| altos | ||
| amt | ||
| colorhug | ||
| csr | ||
| dell | ||
| dfu | ||
| ebitdo | ||
| nitrokey | ||
| steelseries | ||
| synapticsmst | ||
| test | ||
| thunderbolt | ||
| thunderbolt-power | ||
| udev | ||
| uefi | ||
| unifying | ||
| upower | ||
| meson.build | ||
| README.md | ||
Adding a new plugin
An extensible architecture allows for providing new plugin types (for reading and writing different firmware) as well as ways quirk their behavior.
You can find more information about the architecture in the developers section of the fwupd website.
If you have a firmware specification and would like to see support in this project, please file an issue and share the spec. Patches are also welcome.
Plugin interaction
Some plugins may be able to influence the behavior of other plugins. This includes things like one plugin turning on a device, or providing missing metadata to another plugin.
The ABI for these interactions is defined in: https://github.com/hughsie/fwupd/blob/master/src/fu-device-metadata.h
All interactions between plugins should have the interface defined in that file.