The linker does not know which public symbol to call if a plugin calls it's own
symbol. Without this change one plugin could call into another plugin with the
wrong GsPluginData set -- which will probably explode in a ball of flames.
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
If recoldplug is called in the middle of a Thunderbolt firmware update it will
cause the Thunderbolt controller to be in the wrong state and make it appear
that the controller update failed.
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.
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
