c125ec02ed
It wasn't hugely clear what the platform ID was actually meant to represent. In some cases it was being used like a physical ID, in others it was a logical ID, and in others it was both. In some cases it was even used as a sysfs path. Clear up all the confusion by splitting the platform ID into two parts, an optional *physical* ID to represent the electrical connection, and an optional *logical* ID to disambiguate composite devices with the same physical ID. Also create an explicit sysfs_path getter for FuUdevDevice to make this clear. This allows WAIT_FOR_REPLUG to always work, rather than depending on the order that the GUIDs were added, and that the kernel would always return the same sysfs path (which it doesn't have to do, especially for hidraw devices). |
||
|---|---|---|
| .. | ||
| altos | ||
| amt | ||
| colorhug | ||
| csr | ||
| dell | ||
| dell-esrt | ||
| dfu | ||
| ebitdo | ||
| flashrom | ||
| nitrokey | ||
| nvme | ||
| redfish | ||
| steelseries | ||
| superio | ||
| synapticsmst | ||
| test | ||
| thunderbolt | ||
| thunderbolt-power | ||
| udev | ||
| uefi | ||
| unifying | ||
| upower | ||
| wacomhid | ||
| 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.