Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
This function returns a list of sibling devices that have a chosen subsystem,
allowing callers to perform a limited walk of the device tree to locate related
devices.
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
This is typically a Linux sysfs path or USB platform ID and is used in a
different way to the physical ID. The physical ID is only set for some devices
after setup() and depends on the subsystem list, and this would not be defined
for devices that do not match a plugin.
This also fixes an regression where the FuDeviceList fails to match the new
FuUdevDevice device in fu_device_list_get_by_guids_removed() and instead
silently gets 'fixed up' only if FWUPD_DEVICE_FLAG_NO_GUID_MATCHING is not set.
This also allows us to move the various backends device caches to FuBackend as
we now have a suitable ID that is for just the backend to use.
This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
fu_udev_device_ioctl() interprets the return value of ioctl() as the
error cause and generates a misleading error message (permission
denied).
Fix it to use errno for error checking and reporting.
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
This allows the plugin to force a reload of the device using a new GUdevDevice
object. This is required as the values are cached in the immutable object.
We have to supply it when using fu_device_bind_driver(), so we need to get the
old value for ->attach() to avoid guessing what driver was previously loaded.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
If the device node actually provides a vendor string, always use that before
falling back. The flag was initially designed to fall back in the event the NVMe
device does not declare a valid sysfs vendor ID.
