Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry

[Corey Minyard]

On 08/01/2012 08:15 PM, Kevin O'Connor wrote:
> This approach, unfortunately, leads to extra code and "double
> handling" of infomation.
>
> The ultimate consumer of the data wants a binary struct which looks
> like:
>
> struct smbios_type_38 {
>      struct smbios_structure_header header;
>      u8 interface_type;
>      u8 ipmi_version;
>      u8 i2c_slave_addr;
>      u8 nv_storage_dev_addr;
>      u64 base_addr;
>      u8 base_addr_mod_and_irq_info;
>      u8 interrupt_number;
> };
>
> The proposed solution is to put the info in a binary struct which
> looks like:
>
> struct ipmi_info {
>      u8 str_version;
>      u8 interface;
>      u8 reg_space;
>      u8 reg_spacing;
>      u8 slave_addr;
>      u8 irq;
>      u8 version;
>      u8 reserved1;
>      u64 base_addr;
> } PACKED;
>
> and then have SeaBIOS translate the latter binary struct into the
> former.  However, there's no compelling reason to introduce a new
> binary struct instead of using the industry standard binary struct.
>
> I'd prefer QEMU to just pass the SMBIOS struct and let SeaBIOS pass it
> through to the OS.  I also think the existing fw_cfg mechanism for
> passing SMBIOS tables should be used.  I understand that this causes
> some contortions due to the current SMBIOS fw_cfg impementation in
> QEMU, but it seems wrong to introduce a new fw_cfg port that
> accomplishes the same goal as an existing fw_cfg port.

Well, I should also probably add the ACPI name space definition for this 
information, too, and the SMBIOS information is not capable of passing 
all the information required for this (though the above structure can).

I've been studying this, but I don't see an obvious way to dynamically 
add something to the ACPI name space.  At least an easy way.

-corey