Using `sudo FWUPD_PROFILE=10 ./src/fwupd --verbose` will print a
dump of startup times onto the console so that we can debug which
plugin is slowing down system startup. For example:
../src/fu-engine.c:5409:plugins-coldplug [108.55ms]:
../plugins/amt/fu-plugin-amt.c:437:amt [27.14ms]:
:create-context [12.66ms]
:get-version [8.44ms]
:add-device [3.95ms]
To a user there is no point to explicitly showing two failures for
encrypted RAM if the system supports SME and TSME both.
To show them a single failure, de-duplicate the attributes by appstream
ID during depsolve.
If the plugin didn't explicitly set obsoletes and two attributes are both
failures and both share the same appstream ID obsolete one of them.
Wrap the spawned script with an explicit call to the /bin/sh
interpreter needed when running tests in a cross compiled enviroment.
Also increase the timeout for the spawned script to execute to give
enough time for the print to happen in the much slower virtualized
environment.
Change-Id: I71ed377e1bc8db4be4c522cdb9562c1662df7266
The only users of `SERIO\FWID` and `I2C\NAME` are already 'safe' and
the device GUIDs should all be unchanged.
There are no current users of the `MTD\NAME` instance IDs, and these
are the ones that may be more unpredictable and in need of sanity.
The only place we were using the instance ID -> GUID conversion was in
the self tests, and assuming the group is always a GUID removes a lot
of checks from a very hot path at startup.
This allows us to replace the 'dfu-tool replace' with a much more
controlled 'fwupdtool firmware-patch' command that patches at a set of
specific offsets.
Drop in the new functionality into the existing firmware ->write()
vfuncs so that the image headers, footers and/or checksums are correct.
When the child has completed we rely on the next fu_progress_step_done()
call to set the status value back to the parent-defined value. In the
case where there is a delay until the next step is done (e.g. waiting
for hardware to re-enumerate) the child status persisted incorrectly.
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
