This refactors the code as it was getting very confusing; before FuSmbios was
reading both SMBIOS and the kernel-provided DT -- and various things were
injecting overrides in three different place. To properly support FDT remove
one layer of indirection.
This also lets us use the compatible strings to enable plugins specifying the
flag _REQUIRE_HWID -- which means we only load the plugin if it's got a chance
of working. e.g.
[aspeed,ast2500]
When support was added for falling back to SMBIOS data from the kernel
in /sys/class/dmi, we inadvertently stopped caring about the data parsed
directly from DMI tables as first priority. This caused a regression in
hwids from some OEMs that relied upon IDs that could only be properly built
from DMI tables, not the kernel /sys/class/dmi interface.
Link: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1982103
Fixes: 464425fb5 ("SMBIOS: try reading from /sys/class/dmi if direct access fails")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
The raw SMBIOS tables that Linux exposes in /sys/firmware/dmi
are restricted to being readable by root only. If running as
non-root access is still permitted by fields that have been
pre-parsed by the kernel in /sys/class/dmi, most of which are
world-readable. This allows the daemon to load most HWIDs even
if running as a non-root user, as is done on Chromium OS.
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 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
