Hi Patrick,

[Asmitha Karunanithi]

Continuing the discussion in discord here...

Why are we pushing something so Redfish specific down into the dbus
> objects?  (And why isn't it documented as such).  No BIOS that I know of
> has the concept of a "OwningEntity" like this, so they're not passing it
> down to us over PLDM/IPMI.  That means we have to hard code it (via
> configuration of some sort) in bios manager.  Why not just hard code it in
> redfish?


We thought if we can configure "who owns the bios" via pldm, since pldm is
having certain config data through which it creates the biostable.

"For why not redfish?" - I thought why keep registry-related data on
redfish, while the whole registry data is coming from the bios config mgr.
Might be the name here is not correct (owning entity) but we can keep some
relevant name for this field.

I am very much inline with having certain configuration-related data in
bios config mgr and hardcode the necessary data in that file. But even in
that case, these data should be hosted in a dbus object right.

So there can be 2 options: (where my initial thought was to go with option
2 here)
1. If it is "so" redfish specific, we can take it to some redfish
configuration file and read it from there
2. Have the config data in bios config mgr, and then the dbus properties
can be populated from this data.

This is an initial thought of mine, but I am still open to suggestions to
shape this commit in a correct way.

How do we handle BIOS settings which do not go through the
> BIOSConfig/Manager?  BIOSConfig/Manager was intended to hold free-form
> settings which the BMC doesn't want to make dbus objects for each one, but
> some of the BIOS settings come from existing dbus objects (ex. network
> config is one of them).

Patrick, I am not aware of certain bios settings that do not go through
bios config mgr. Can you please point me to that?
Because I think that is still going through bios config mgr, meaning even
if there are certain dbus objects, (network config in this case), the
properties of those dbus objects are being written into the bios config mgr
(so if we try to access the biostable, we will get those n/w attributes
also as a part of bios schema)
Please correct me if I am wrong.

How do we handle a system with multiple BIOSConfig/Manager objects?
> Previously I think there was just a single one, but with the concept of
> versions (and different owners) we're going to need to handle multiple of
> them.

If I am assuming correct, you are pointing out the case of a bladed system,
where there will be multiple BIOS vendors? In that case, each of the
systems will be having different system objects (with unique id) and each
of them will have their bios objects.

"but with the concept of versions (and different owners) we're going to
> need to handle multiple of them."

I am not following here.
In redfish, there is a concept of versioning and owner and we thought if we
can extend it here in the backend as well, which is the intent of adding
these two fields in this commit.

I will read up more on the redfish spec.

I think the version can be removed in my change (and leave it hardcoded
like it is being done currently) but I feel there should be an option to
define who is the "owner of bios", where we can mention the different
owners (vendors) of bios and also maybe, have the "name of the registry"
defined.
(again this goes back to the first point above).

Ed, your thoughts here would also be really helpful.

-- 
Thanks & Regards,
Asmitha Karunanithi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210519/4ef9950e/attachment.htm>