From: "Garrett, Mike (HPE Server Firmware)" <email@example.com>
To: Artem Senichev <firstname.lastname@example.org>
Cc: OpenBMC Maillist <email@example.com>,
"Pedrana, Nick" <firstname.lastname@example.org>
Subject: RE: Leveraging and extending smbios-mdr
Date: Tue, 17 Aug 2021 21:29:32 +0000 [thread overview]
Message-ID: <DF4PR8401MB0634FB1810144BBDB9C42E158FFE9@DF4PR8401MB0634.NAMPRD84.PROD.OUTLOOK.COM> (raw)
Actually I'm talking about https://github.com/openbmc/smbios-mdr
It looks like this daemon tries to take in a data file at startup only (/var/lib/smbios/smbios/smbios2). I'm wondering if there's a provision in the design to refresh the data file if appears or is updated later. This file (at least in my experience) has to be created by an interaction with the BIOS during boot. So it would be very reasonable for the BMC to boot before the host and there to be no file available yet. Also, if something is updated on the host, a reboot may refresh this file. So I think there are a couple of reasons why it would be good for this repo to react to data file updates.
If it doesn't exist and folks think it's a good idea, we can look at creating that capability, but I want to make sure it doesn't already exist.
> -----Original Message-----
> From: Artem Senichev <email@example.com>
> Sent: Thursday, July 29, 2021 2:49 AM
> To: Garrett, Mike (HPE Server Firmware) <firstname.lastname@example.org>
> Cc: OpenBMC Maillist <email@example.com>; Pedrana, Nick
> Subject: Re: Leveraging and extending smbios-mdr
> On Tue, Jul 27, 2021 at 03:47:04PM +0000, Garrett, Mike (HPE Server
> Firmware) wrote:
> > Hello Artem and all,
> > We are integrating smbios-mdr into our build. Our SMBIOS info is
> downloaded and built as a file in the filesystem using proprietary means (our
> CHIF - channel interface). Our hope is that we can simply point the smbios-
> mdr service at it and light up new information about the platform in dbus,
> Redfish, and the GUI.
> > However, I can't find much in the way of documentation about smbios-
> If we are talking about the MDR2 project (https://github.com/Intel-
> there is no documentation, but I don't think we really need it.
> It is just a SMBIOS dump parser for some table types (CPU, DIMM).
> The table format is fully documented in the SMBIOS specification:
> > I'm especially interested in how to extend the functionality past just CPUs
> and DIMMs into things like OEM records supplied by the BIOS.
> What about phosphor-inventory-manager?
> > Seems like the possibilities are:
> > 1. Smbios-mdr has a generic dbus API and we write an independent
> > service to query it for this info and publish to dbus 2. We create a
> > generic extension mechanism for smbios-mdr for vendors to add OEM
> support and push to dbus directly from smbios-mdr (like w/ CPUs/DIMMs) 3.
> We fork smbios-mdr and extend it (not preferred).
> > I'd like to hear how best to leverage this recipe.
> Artem Senichev
> Software Engineer, YADRO.
next prev parent reply other threads:[~2021-08-17 21:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 15:47 Leveraging and extending smbios-mdr Garrett, Mike (HPE Server Firmware)
2021-07-29 7:49 ` Artem Senichev
2021-08-17 21:29 ` Garrett, Mike (HPE Server Firmware) [this message]
2021-08-18 6:33 ` Andrei Kartashev
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).