The kernel allows configuring this, and certain plugins will use this
path to be able to load firmware in the kernel driver through runtime,
but to flash to the device.
This allows for proper locking between executions of fwupdtool in
Chromium OS minijail environment. It is needed after commit
9cf5f8f7ff was introduced.
Change-Id: I37b33c8d1fbe97ec9baddc5f77ea94e2f4ff1fa4
This allows plugins to set the battery power state of the *machine* which means
we can automatically inhibit devices with FWUPD_DEVICE_FLAG_REQUIRE_AC set.
It also allows to set the BatteryThreshold to 25% for Lenovo hardware, and we
can override other vendors with further quirks as required.
Fixes https://github.com/fwupd/fwupd/issues/3084
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
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.
It is impossible to choose a static default that is appropriate for both a tiny
ARM IoT device and a giant Xeon server.
Fixes https://github.com/fwupd/fwupd/issues/2760
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
