It turns out we do not want to know the current phase of the device, and we can
achieve the same thing tagging the GUsbDevice manually and clearing the events
at exactly the correct time.
This only have any protective effect if we're using multiple threads -- which
we're not. Removing these unused locks does not affect startup speed, but does
drop the idle RSS by ~10kB.
This would allow us to convert more easily to a built-in plugin in the future
and means we match the source style used in 97% of the other plugins.
No logic changes.
This adds 7 pointer-size blocks of wasted space for each modular plugin, and
three pointers for builtin plugins, but allows us to use the exact same vfuncs
when building plugins in either mode.
This will allow us to convert nearly all the plugins to being builtin.
If a specific plugin calls fu_plugin_set_secure_config_value() and then
fu_plugin_set_config_value() then we'll save the file with the world-readable
permissions.
Set a plugin flag to say that 'this plugin is storing sensitive details' which
allows us to use the same entrypoint and also fix up any files at startup that
do not have the correct permissions.
When the redfish plugin automatically creates an OPERATOR user account on the
BMC we save the autogenerated password to /etc/fwupd/redfish.conf, ensuring it
is chmod'ed to 0660 before writing the file with g_key_file_save_to_file().
Under the covers, g_key_file_save_to_file() calls g_file_set_contents() with
the keyfile string data.
I was under the impression that G_FILE_CREATE_REPLACE_DESTINATION was being
used to copy permissions, but alas not.
GLib instead calls g_file_set_contents_full() with the mode hardcoded to 0666,
which undoes the previous chmod().
Use g_file_set_contents_full() with the correct mode for newer GLib versions,
and provide a fallback with the same semantics for older versions.
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This allows creating the silo when starting the engine with custom
plugin keys such as WacomI2cFlashBaseAddr.
If we move the plugin initialization earlier then we don't get the
HwID matches, so we really do have to split this into a 4-stage startup,
e.g. ->load(), ->init(), ->startup() and ->coldplug().
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
At the moment a lot of the failures are only visible when running the
daemon in verbose mode, and the inhibit functionalit provides us a way
to unset FWUPD_DEVICE_FLAG_UPDATABLE from multiple places, as well as
setting the update error for the user to see why.
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
During my fwupd startup fu_plugin_has_custom_flag gets called 21 times
which causes all HWIDs to be enumerated with 346 calls to the quite
expensive fu_context_lookup_quirk_by_id() function.
Move the flag to a private hashset and enumerate the HWIDs only during
startup. There's nothing plugin specific about them anyway...
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
