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