This allows a plugin to see if a GUID is supported in the AppStream metadata of
configured remotes. It allows plugins to skip devices that are not supported
and that do bad things when probed.
By removing the device from the hash table before we add it to the devices
array we could inadvertently drop the last object reference if the plugin is
not using the (optional) cache.
Just re-arrange things to fix https://github.com/hughsie/fwupd/issues/259
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the former, and that's how plugins are using it.
The Linux DMI class still does not provide the information we need, and parsing
the blob directly also allows the Dell and Redfish plugins to get the raw data.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
This could be used, for instance, to set a property on ThunderBolt controllers
inside Dell computers saying that they support forcing the power level during
coldplug. It could also be used to set the dock type for the synapticsmst hub.
Adding this level of complexity allows us to avoid the creep of HAVE_DELL and
HAVE_LENOVO into seemingly unrelated plugins, and also allows us to have
multiple vendor plugins providing the same end result with two different
vendor-specific mechanisms.
Although we supported other hashes than SHA1 (which is now moderately unsafe)
we had to switch the metadata provider and daemon on some kind of flag day to
using SHA256. Since that's somewhat impractical, just allow multiple checksums
to be set on objects and just try to match whatever is given in preference
order.
This also means we can easily transition to other hash types in the future.
The removed API was never present in a tarball release, so not an API break.
This commit provides a new "hwids" subcommand for fwupdmgr that shows the
hardware GUIDs on the local system. It also provides API that plugins can use
to self-disable when a specific HWID does not match.
The GUIDs used in this implementation match that of ComputerHardwareIds.exe
Packagers should still enable it so that tracking lost memory
in plugins is possible, but on some distros some archs don't
have valgrind available which would otherwise prevent fwupd
from running.
This is as problem currently for Debian unstable where some
archs valgrind fails to compile.
Poll each plugin, and only register the service when all the delayed coldplug
devices have been added to the device list. This prevents returning an error
when calling "fwupdmgr get-devices" for the very first time.
Resolves: https://github.com/hughsie/fwupd/issues/82
This allows a plugin to signal the daemon that something has happened and that
all plugins should wake up connected devices, re-add them all and then put the
devices back to powersave mode. Any duplicate devices will be ignored.
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
This means we don't have more that one thread just watching for the USB
hotplug events. To achieve this split up the coldplug into setup and coldplug
phases and run the enumerate just once in the daemon.
