This allows a frontend to call update on an individual device ID which will
cause a CAB file to be downloaded, but then also re-use the same CAB file to
try to process devices with a relationship as part of a transaction.
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.
The profiling data is of limited use, and better data can be obtained using
kcachegrind and massif. Additionally, the profile samples were the cause of the
small RSS growth over time, when in reality the data would only be shown when
the verbose switch is used at daemon startup.
Since it matches the Realtek dongle, shouldn't show this error:
failed to add USB device 0bda:8153: no dock detected
All the time when that dongle is plugged in
It seems the 'Notebook' vendor is padded with spaces in the DMI data, and so
the GUID changes now we're following the same stripping scheme of Windows 10.
Now devices can have multiple GUIDs and do not share platform IDs there is
really no point waiting to add the device.
This allows us to remove a whole lot of code for this now-unused functionality.
This started popping up in Arch CI:
../fwupd/plugins/uefi/fu-uefi-vars.c: In function ‘fu_uefi_vars_get_data’:
../fwupd/plugins/uefi/fu-uefi-vars.c:233:9: error: pointer targets in assignment from ‘gchar *’ {aka ‘char *’} to ‘guint8 *’ {aka ‘unsigned char *’} differ in signedness [-Werror=pointer-sign]
*data = g_steal_pointer (&data_tmp);
^
Until now, the unifying plugin was a 'special snowflake' and did things in very
different ways to the other plugins. Refactor each object to derive from either
FuUsbDevice or FuUdevDevice, and then remove LuDevice and the LuContext layers.
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).
As an example use case earlier development versions of a Thunderbolt module
may contain DROM corresponding to one model ID and transition to another
model ID. Even if lying about the GUIDs supported by the device via a
quirk the Thunderbolt validation will fail because the device isn't
intended for that system.
This should only be used during development.
The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
