a. An option name is associated with a data type, regardless of data source. Based on the data type, appropriate vpd_get_* can be used. get_option() takes option name as input, it looks up at a table to get the data type, pass the option name and data type to vpd_get_option(). vpd_get_option() calls appropriate vpd_get_* based on data type, to look up the option name. In other words, the vpd_get_option() design is very similar to cmos_get_option().

There is no general need for tables. The CMOS "option table" is only
a table because CMOS space is so tight that we have to pack things.
The current get_option() API is definitely at an impasse. Beside the
lack of typing, it's dangerous because the caller has no way to pass
the length of storage available.

We have all the type information in C code and should make use of
it. That needs a new API, ofc. For instance, integer and enum values
could simply be read with a get_int_option() function, booleans with
a get_bool_option(). Well, for enums there could be look-up tables
if one wants to store strings in the backend, for instance. But such
information should be provided by the caller, not the backend.

c. For a specific option, there are several possible sources (cmos/cbfs/vpd/gpio/i2c, etc). For a mainboard, not all options may come from same source. A mainboard will have a table to enumerate which option comes from which source.

Sounds possible, but should be optional. Not everybody needs multiple
sources. In the core I would keep things as simple as possible.

View Change

To view, visit change 45774. To unsubscribe, or for help writing mail filters, visit settings.