Excerpts from Jonathan Toppins's message of 2017-07-17 20:26 -04:00:
We need two sets of firmware info, system level info to track what
version of BIOS0 is installed on a machine, these entries here. And
device level info to track what firmware, if any, is on a given PCI
connected device, the additions below. It is currently our understanding
that the layout is something like
system_entry -> device_entry
device_entry
A system_entry exists in a different table from device_entries hence why
we decided to use two different sets of data, thus the two changes.
Maybe I misunderstood the DB schema and device entries are reused for a
singular machine entry?
The catch for the system level firmware is it must be directly
associated with a given FQDN, i.e. it is a property of an FQDN.
Hopefully this makes a little more sense as to why there are two sets of
firmware entries, it was intentional - maybe not needed :-D
Okay I gotcha. Didn't realise that's what you were going for.
So in lshw's output, the "system firmware" is actually just represented
as another node in the tree of devices (at the top, as a direct child of
the "core" node at the root). Which is a neat idea, because it makes the
data model simpler, you don't need any special case for "the system
itself", it just appears similar to any other device. And that gives you
other stuff about the firmware too like the vendor name, which is not
necessarily the same as the vendor of the system itself.
So right now the lshw node for system firmware is just ignored by
beaker-system-scan. But maybe we can make it include it in the list of
devices? Perhaps with some special value for the "type" or "bus"
fields.
That means in Beaker we would only need to add fw_version and fw_date
fields in one place, and only add one set of new search filters instead
of two, etc.
Ultimately I would like to evolve Beaker's idea of "devices" to be
closer to the lshw tree model because it seems to be a good way of
generically describing a lot of different hardware. Not saying we need
to go full speed down this route right now -- but anything that brings
Beaker's model of devices closer to lshw's seems worthwhile to me.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat