<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I am looking at enabling firmware updates for some auxiliary components in our servers that don’t fall into the “BMC”, “Host” or “PSU” bucket. I’m trying to understand if there is a pattern I am missing, what other people are doing, and
the possibility of changing the design.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Right now it looks like the path forward would be to extend the “Version.interface.yaml” in the “phosphor-dbus-interfaces” repo (<a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/6f69ae5b33ee224358cb4c2061f4ad44c6b36d70/xyz/openbmc_project/Software/Version.interface.yaml">https://github.com/openbmc/phosphor-dbus-interfaces/blob/6f69ae5b33ee224358cb4c2061f4ad44c6b36d70/xyz/openbmc_project/Software/Version.interface.yaml</a>)
and add new VersionPurpose for each component. Then update the Image Manager, Item Updater, BMCWeb, etc to handle the new component types. This seems like this would be touching components up and down the stack just to extend. Is there some other pattern
or way of extending the software manager to handle new components?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What are people doing for components like this? Are they just updating them offline, e.g. you have command line tools to update the firmware for a component that are executed from a terminal/ssh session? Are all of these components just
included in the BMC image tar and then either based on the files in there update sub-components (similar to the image-bmc vs image-kernel + image-rofs)? Are the components just included in the BMC image itself so it updates all components to the current on
boot? Something else?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When I look at the design, it seems like using an enum for the “VersionPurpose” is a little too restrictive. It doesn’t allow for other components to be added, other than the “Other” enum entry. But there isn’t an extended purpose string
to allow specifying what that “Other” value actually means. I couldn’t find an easy way to search through the archive for design discussions around the phosphor software management, are there any reasons why this isn’t a generic string? Or important discussions
around the current design that I can look through?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"> Derek<o:p></o:p></p>
</div>
</body>
</html>