<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt">Hi Vernon,</span> </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="margin:0px; font-size:12pt"><br>
</div>
<div style="margin:0px; font-size:12pt">Thanks for your <span style="background-color:rgb(255,255,255); display:inline!important">
detailed </span>explanation, I got a lot of concepts from it and realized how should I carry on next.</div>
<div style="margin:0px; font-size:12pt"><br>
</div>
<div style="margin:0px; font-size:12pt">However, I'm not sure whether my understanding of the filter is correct, so would like to confirm with you further.
<div style="margin:0px"><br>
</div>
<div style="margin:0px">
<ul>
<li>If I for now have 3 IPMI provider libraries, such as the original library in "phosphor-host-ipmid", "<span style="margin:0px; background-color:rgb(255,255,255); display:inline!important">intel-ipmi-oem"<span style="margin:0px"> </span></span>and "my own
library", and they all have their own filter with whitelist. These 3 filters will all be registered. Then, when a command comes in, this command will be passed to each filter and check if the command exists in their whitelist. Am I correct?</li></ul>
<ul>
<li>If yes in above, that means I just need to add the command's NetFn/CommandID in one of these 3 whitelists, the command still will be passed to a specific provider once it exists in one of the whitelists? Or I should add that command's NetFn/Command to the
whitelist of its dedicated library?</li></ul>
</div>
</div>
<div style="margin:0px; font-size:12pt"><br>
</div>
<div style="margin:0px; font-size:12pt">Regards,</div>
<span style="margin:0px; font-size:12pt">Chris Chen</span><br>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>寄件者:</b> Vernon Mauery <vernon.mauery@linux.intel.com><br>
<b>寄件日期:</b> 2021年9月10日 上午 04:15<br>
<b>收件者:</b> Chris Chen (TPI) <Chris.Chen3@flex.com><br>
<b>副本:</b> openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org><br>
<b>主旨:</b> Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On 06-Sep-2021 09:40 AM, Chris Chen (TPI) wrote:<br>
>Hi all,<br>
><br>
>I guess this mail was got overwhelmed by bunches of emails, so please let me resend it and hope someone could help me. Another, I add one more question marked #5 below.<br>
<br>
Thanks for being persistent :)<br>
<br>
><br>
>Hi all,<br>
><br>
>I have studied "phosphor-host-ipmid" package for a couple of weeks and got understanding that it has implemented some mandatory and optional commands already. And I also knew that I'm able to leverage "intel-ipmi-oem" package to get more command handlers.
But there're some questions raised in my mind, I hope someone could give me some suggestions.<br>
><br>
> 1. What's the normal development procedure in case I want to make our own OEM commands? I mean do you guys encourage me to create a new "xxx-ipmi-oem" package or to leverage "intel-ipmi-oem" and then add our own commands in it?<br>
<br>
First some common language:<br>
1) xxx-ipmi-oem is an IPMI provider library. It doesn't need to be <br>
called xxx-ipmi-oem, but that is just a convenient naming convention.<br>
2) whitelist (prefer allowlist) is one kind of filter. Filters are <br>
registered like command handlers, with a priority. Filters can do more <br>
than just block or allow the commands coming in. The filter is passed <br>
the request and can do anything it wants before passing it on. Logging, <br>
mangling, blocking, etc.<br>
<br>
It depends on a lot of things. Maybe yes, create a new repo? More <br>
discussion below.<br>
<br>
> 2. I for now added "intel-ipmi-oem" package only for using its "<Chassis>:<Set Front Panel Enables>" command because I figured out the same command in the "phosphor-host-ipmid" is not able to match the d-bus interface in the "x86-power-control". I'm not
sure if I will need other commands in the "intel-ipmi-oem", but what if I don't need other commands, how to remove them? to use the whitelist mechanism?<br>
<br>
There is not a method to remove them, but you can filter them as you <br>
suggested. Also, if you want to add a different implementation (from a <br>
different IPMI provider library) at a higher priority, only the higher <br>
priority implementation will be used.<br>
<br>
> 3. Is it okay to add more than 1 xxx-ipmi-ome packages? If yes, how to manage the whitelist between these 2 OEM packages?<br>
<br>
You can have as many IPMI provider libraries on the BMC as needed.<br>
<br>
The filtering mechanism does not discriminate between the provider, it <br>
is used at execution time when a command comes in. Every command is <br>
passed to each filter <br>
<br>
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?<br>
<br>
IANAL, but, yes. It is open source and the license does not make that <br>
restriction. It might look kind of weird though :)<br>
<br>
If you like all the IPMI functions implemented by the intel-ipmi-oem, it <br>
is fine to use it as is. If there are things you want to change, there <br>
are different ways to go about it.<br>
<br>
Here are a couple of scenarios with some options:<br>
1) You like the behavior of an IPMI provider library, but want some <br>
changes. Talk with the owner and see if you can come to some consensus <br>
that works for everyone. This is the most opensource, <br>
community-building, good-will behavior of all. Submit a change and see <br>
if you can get it merged.<br>
<br>
2) You like all the IPMI commands in an IPMI provider library except for <br>
one or two. If you want to own the work to keep a patch up to date, it <br>
is possible to just add a bbappend and a patch to modify the code prior <br>
to building. This is okay, but maybe not as ideal. It may end up with a <br>
smaller image size than adding a new provider library to overload the <br>
command implementation.<br>
<br>
3) You like all the IPMI commands in an IPMI provider library except for <br>
one or two. You can create a new IPMI provider library for your <br>
organization that can filter out and/or provide overloads for any <br>
existing implementation of IPMI commands from any number of other IPMI <br>
providers.<br>
<br>
4) You only like some bits of another IPMI provider. You may be best off <br>
to just copy those bits into a new IPMI provider library of your own, <br>
add your own other OEM commands and/or implementations and carry on.<br>
<br>
Really, none of the 'solutions' are ideal, but we are trying to make <br>
trade-offs here that allow individual contributing organizations freedom <br>
to implement OEM commands as they wish without any one organization <br>
being a gatekeeper.<br>
<br>
--Vernon<br>
</div>
</span></font></div>
</div>
<DIV>
Legal Disclaimer :<BR>
The information contained in this message may be privileged and confidential. <BR>
It is intended to be read only by the individual or entity to whom it is addressed <BR>
or by their designee. If the reader of this message is not the intended recipient, <BR>
you are on notice that any distribution of this message, in any form, <BR>
is strictly prohibited. If you have received this message in error, <BR>
please immediately notify the sender and delete or destroy any copy of this message!<BR>
</DIV></body>
</html>