* RE: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-06 9:40 ` 回覆: " Chris Chen (TPI)
@ 2021-09-06 10:03 ` Troy Lee
2021-09-07 0:25 ` 回覆: " Chris Chen (TPI)
2021-09-06 10:15 ` Andrei Kartashev
2021-09-09 20:15 ` Vernon Mauery
2 siblings, 1 reply; 12+ messages in thread
From: Troy Lee @ 2021-09-06 10:03 UTC (permalink / raw)
To: Chris Chen (TPI), openbmc
Hi,
Using ```journalctl -o json-pretty```, you will see other entries in each log.
Thanks,
Troy Lee
From: openbmc <openbmc-bounces+troy_lee=aspeedtech.com@lists.ozlabs.org> On Behalf Of Chris Chen (TPI)
Sent: Monday, September 6, 2021 5:41 PM
To: openbmc@lists.ozlabs.org
Subject: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi all,
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.
Thank you.
Regards,
Chris Chen
________________________________________
寄件者: openbmc <mailto:openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Chris Chen (TPI) <mailto:Chris.Chen3@flex.com>
寄件日期: 2021年9月2日 下午 06:34
收件者: mailto:openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi all,
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.
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?
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?
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?
4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I mean I for now can print out "Set up ipmi context" string after following the instruction listed in "https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC#enabling-application-debug", but I don't see "SENDER=" when I executed "journalctl -t ipmid" command.
6.
6. log<level::DEBUG>("Set up ipmi context", entry("SENDER=%s", sender.c_str()),
entry("NETFN=0x%X", netFn), entry("LUN=0x%X", lun),
entry("CMD=0x%X", cmd), entry("CHANNEL=%u", channel),
entry("USERID=%u", userId),
entry("SESSIONID=0x%X", sessionId),
entry("PRIVILEGE=%u", static_cast<uint8_t>(privilege)),
entry("RQSA=%x", rqSA));
Thank you.
Regards,
Chris Chen
Legal Disclaimer :
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is addressed
or by their designee. If the reader of this message is not the intended recipient,
you are on notice that any distribution of this message, in any form,
is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this message!
^ permalink raw reply [flat|nested] 12+ messages in thread* 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-06 10:03 ` Troy Lee
@ 2021-09-07 0:25 ` Chris Chen (TPI)
0 siblings, 0 replies; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-07 0:25 UTC (permalink / raw)
To: Troy Lee, openbmc
[-- Attachment #1: Type: text/plain, Size: 3994 bytes --]
Hi Troy,
I'm able to see other entries now, thanks for your sharing.
Regards,
Chris Chen
________________________________
寄件者: Troy Lee <troy_lee@aspeedtech.com>
寄件日期: 2021年9月6日 下午 06:03
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: RE: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi,
Using ```journalctl -o json-pretty```, you will see other entries in each log.
Thanks,
Troy Lee
From: openbmc <openbmc-bounces+troy_lee=aspeedtech.com@lists.ozlabs.org> On Behalf Of Chris Chen (TPI)
Sent: Monday, September 6, 2021 5:41 PM
To: openbmc@lists.ozlabs.org
Subject: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi all,
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.
Thank you.
Regards,
Chris Chen
________________________________________
寄件者: openbmc <mailto:openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Chris Chen (TPI) <mailto:Chris.Chen3@flex.com>
寄件日期: 2021年9月2日 下午 06:34
收件者: mailto:openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi all,
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.
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?
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?
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?
4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I mean I for now can print out "Set up ipmi context" string after following the instruction listed in "https://urldefense.com/v3/__https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC*enabling-application-debug__;Iw!!HSntlCg!ER4F5EQKDfxZDhlNbj_u-37VaIuI_kgky8ZqGuiosmru--vFGjEsT4cP0_AxOQH9$ ", but I don't see "SENDER=" when I executed "journalctl -t ipmid" command.
6.
6. log<level::DEBUG>("Set up ipmi context", entry("SENDER=%s", sender.c_str()),
entry("NETFN=0x%X", netFn), entry("LUN=0x%X", lun),
entry("CMD=0x%X", cmd), entry("CHANNEL=%u", channel),
entry("USERID=%u", userId),
entry("SESSIONID=0x%X", sessionId),
entry("PRIVILEGE=%u", static_cast<uint8_t>(privilege)),
entry("RQSA=%x", rqSA));
Thank you.
Regards,
Chris Chen
Legal Disclaimer :
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is addressed
or by their designee. If the reader of this message is not the intended recipient,
you are on notice that any distribution of this message, in any form,
is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this message!
[-- Attachment #2: Type: text/html, Size: 6487 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-06 9:40 ` 回覆: " Chris Chen (TPI)
2021-09-06 10:03 ` Troy Lee
@ 2021-09-06 10:15 ` Andrei Kartashev
2021-09-07 0:35 ` 回覆: " Chris Chen (TPI)
2021-09-09 20:15 ` Vernon Mauery
2 siblings, 1 reply; 12+ messages in thread
From: Andrei Kartashev @ 2021-09-06 10:15 UTC (permalink / raw)
To: Chris Chen (TPI), openbmc
Hello,
I don't represent Intel, but have some considerations about this topic:
1) Try to not reuse intel-ipmi-oem. Much better solution would be to
create your own xxx-ipmi-oem package and implement only methods you
really need.
2) Better way would be to implement required logic in phosphor-host-
ipmid and submit changes there. I didn't investigate this yet since we
also pull intel-ipmi-oem to our project, but I believe, it should not
be too difficult. Don't repeat our mistakes ).
3) There is priority argument which you can use to determine handler
call order.
4) Most functions there are specific for Intel servers, so the useless
even is you use Intel CPUs but your own platform.
5) Use "journalctl -t ipmid -o pretty-json" or something like this. But
now it is recommended to use new syntax:
https://github.com/openbmc/phosphor-logging/blob/master/docs/structured-logging.md
On Mon, 2021-09-06 at 09:40 +0000, Chris Chen (TPI) wrote:
> Hi all,
>
> 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.
>
> Thank you.
>
> Regards,
> Chris Chen
>
> 寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表
> Chris Chen (TPI) <Chris.Chen3@flex.com>
> 寄件日期: 2021年9月2日 下午 06:34
> 收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> 主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command
> development
> Hi all,
>
> 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.
> 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?
> 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?
> 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?
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD
> CPU?
> 5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I
> mean I for now can print out "Set up ipmi context" string after
> following the instruction listed in
> "https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC#enabling-application-debug
> ", but I don't see "SENDER=" when I executed "journalctl -t ipmid"
> command.
> 6. 1. log<level::DEBUG>("Set up ipmi
> context",entry("SENDER=%s",sender.c_str()),
> entry("NETFN=0x%X", netFn),entry("LUN=0x%X", lun),
> entry("CMD=0x%X", cmd),entry("CHANNEL=%u", channel),
> entry("USERID=%u", userId),
> entry("SESSIONID=0x%X", sessionId),
> entry("PRIVILEGE=%u",static_cast<uint8_t>(privilege)),
> entry("RQSA=%x", rqSA));
> Thank you.
>
> Regards,
> Chris Chen
> Legal Disclaimer :
> The information contained in this message may be privileged and
> confidential.
> It is intended to be read only by the individual or entity to whom it
> is addressed
> or by their designee. If the reader of this message is not the intended
> recipient,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of
> this message!
--
Best regards,
Andrei Kartashev
^ permalink raw reply [flat|nested] 12+ messages in thread* 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-06 10:15 ` Andrei Kartashev
@ 2021-09-07 0:35 ` Chris Chen (TPI)
2021-09-07 9:52 ` Chris Chen (TPI)
0 siblings, 1 reply; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-07 0:35 UTC (permalink / raw)
To: Andrei Kartashev, openbmc
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]
Hi Anrdrei,
Thank you for your helpful comments.
Regards,
Chris Chen
________________________________
寄件者: Andrei Kartashev <a.kartashev@yadro.com>
寄件日期: 2021年9月6日 下午 06:15
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hello,
I don't represent Intel, but have some considerations about this topic:
1) Try to not reuse intel-ipmi-oem. Much better solution would be to
create your own xxx-ipmi-oem package and implement only methods you
really need.
2) Better way would be to implement required logic in phosphor-host-
ipmid and submit changes there. I didn't investigate this yet since we
also pull intel-ipmi-oem to our project, but I believe, it should not
be too difficult. Don't repeat our mistakes ).
3) There is priority argument which you can use to determine handler
call order.
4) Most functions there are specific for Intel servers, so the useless
even is you use Intel CPUs but your own platform.
5) Use "journalctl -t ipmid -o pretty-json" or something like this. But
now it is recommended to use new syntax:
https://urldefense.com/v3/__https://github.com/openbmc/phosphor-logging/blob/master/docs/structured-logging.md__;!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6cseru6Bcw$
On Mon, 2021-09-06 at 09:40 +0000, Chris Chen (TPI) wrote:
> Hi all,
>
> 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.
>
> Thank you.
>
> Regards,
> Chris Chen
>
> 寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表
> Chris Chen (TPI) <Chris.Chen3@flex.com>
> 寄件日期: 2021年9月2日 下午 06:34
> 收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> 主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command
> development
> Hi all,
>
> 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.
> 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?
> 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?
> 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?
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD
> CPU?
> 5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I
> mean I for now can print out "Set up ipmi context" string after
> following the instruction listed in
> "https://urldefense.com/v3/__https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC*enabling-application-debug__;Iw!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6csVZtHYM2$
> ", but I don't see "SENDER=" when I executed "journalctl -t ipmid"
> command.
> 6. 1. log<level::DEBUG>("Set up ipmi
> context",entry("SENDER=%s",sender.c_str()),
> entry("NETFN=0x%X", netFn),entry("LUN=0x%X", lun),
> entry("CMD=0x%X", cmd),entry("CHANNEL=%u", channel),
> entry("USERID=%u", userId),
> entry("SESSIONID=0x%X", sessionId),
> entry("PRIVILEGE=%u",static_cast<uint8_t>(privilege)),
> entry("RQSA=%x", rqSA));
> Thank you.
>
> Regards,
> Chris Chen
> Legal Disclaimer :
> The information contained in this message may be privileged and
> confidential.
> It is intended to be read only by the individual or entity to whom it
> is addressed
> or by their designee. If the reader of this message is not the intended
> recipient,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of
> this message!
--
Best regards,
Andrei Kartashev
[-- Attachment #2: Type: text/html, Size: 7719 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-07 0:35 ` 回覆: " Chris Chen (TPI)
@ 2021-09-07 9:52 ` Chris Chen (TPI)
2021-09-07 11:45 ` Chris Chen (TPI)
0 siblings, 1 reply; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-07 9:52 UTC (permalink / raw)
To: Andrei Kartashev, openbmc
[-- Attachment #1: Type: text/plain, Size: 5500 bytes --]
Hi Andrei,
One more thing would like to consult you is I have tried to add our own xxx-ipmi-oem, but got the "Insufficient privilege level" feedback after executing an oem command. However, it would be successful in case I removed intel-ipmi-oem. Do you have experience with this? If yes, may I know how to fix it?
I currently would like to keep leveraging the intel-ipmi-oem until I integrate the commands I needed into our own xxx-ipmi-oem.
Thank you.
Regards,
Chris Chen
________________________________
寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Chris Chen (TPI) <Chris.Chen3@flex.com>
寄件日期: 2021年9月7日 上午 08:35
收件者: Andrei Kartashev <a.kartashev@yadro.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi Anrdrei,
Thank you for your helpful comments.
Regards,
Chris Chen
________________________________
寄件者: Andrei Kartashev <a.kartashev@yadro.com>
寄件日期: 2021年9月6日 下午 06:15
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hello,
I don't represent Intel, but have some considerations about this topic:
1) Try to not reuse intel-ipmi-oem. Much better solution would be to
create your own xxx-ipmi-oem package and implement only methods you
really need.
2) Better way would be to implement required logic in phosphor-host-
ipmid and submit changes there. I didn't investigate this yet since we
also pull intel-ipmi-oem to our project, but I believe, it should not
be too difficult. Don't repeat our mistakes ).
3) There is priority argument which you can use to determine handler
call order.
4) Most functions there are specific for Intel servers, so the useless
even is you use Intel CPUs but your own platform.
5) Use "journalctl -t ipmid -o pretty-json" or something like this. But
now it is recommended to use new syntax:
https://urldefense.com/v3/__https://github.com/openbmc/phosphor-logging/blob/master/docs/structured-logging.md__;!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6cseru6Bcw$
On Mon, 2021-09-06 at 09:40 +0000, Chris Chen (TPI) wrote:
> Hi all,
>
> 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.
>
> Thank you.
>
> Regards,
> Chris Chen
>
> 寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表
> Chris Chen (TPI) <Chris.Chen3@flex.com>
> 寄件日期: 2021年9月2日 下午 06:34
> 收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> 主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command
> development
> Hi all,
>
> 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.
> 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?
> 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?
> 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?
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD
> CPU?
> 5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I
> mean I for now can print out "Set up ipmi context" string after
> following the instruction listed in
> "https://urldefense.com/v3/__https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC*enabling-application-debug__;Iw!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6csVZtHYM2$
> ", but I don't see "SENDER=" when I executed "journalctl -t ipmid"
> command.
> 6. 1. log<level::DEBUG>("Set up ipmi
> context",entry("SENDER=%s",sender.c_str()),
> entry("NETFN=0x%X", netFn),entry("LUN=0x%X", lun),
> entry("CMD=0x%X", cmd),entry("CHANNEL=%u", channel),
> entry("USERID=%u", userId),
> entry("SESSIONID=0x%X", sessionId),
> entry("PRIVILEGE=%u",static_cast<uint8_t>(privilege)),
> entry("RQSA=%x", rqSA));
> Thank you.
>
> Regards,
> Chris Chen
> Legal Disclaimer :
> The information contained in this message may be privileged and
> confidential.
> It is intended to be read only by the individual or entity to whom it
> is addressed
> or by their designee. If the reader of this message is not the intended
> recipient,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of
> this message!
--
Best regards,
Andrei Kartashev
[-- Attachment #2: Type: text/html, Size: 10205 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-07 9:52 ` Chris Chen (TPI)
@ 2021-09-07 11:45 ` Chris Chen (TPI)
0 siblings, 0 replies; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-07 11:45 UTC (permalink / raw)
To: Andrei Kartashev, openbmc
[-- Attachment #1: Type: text/plain, Size: 6073 bytes --]
Hi Andrei,
I think I have figured out the root cause that's I didn't add the command in the ipmi-whitelist.conf within the intel-ipmi-oem. Thank you all the same.
Regards,
Chris Chen
________________________________
寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Chris Chen (TPI) <Chris.Chen3@flex.com>
寄件日期: 2021年9月7日 下午 05:52
收件者: Andrei Kartashev <a.kartashev@yadro.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi Andrei,
One more thing would like to consult you is I have tried to add our own xxx-ipmi-oem, but got the "Insufficient privilege level" feedback after executing an oem command. However, it would be successful in case I removed intel-ipmi-oem. Do you have experience with this? If yes, may I know how to fix it?
I currently would like to keep leveraging the intel-ipmi-oem until I integrate the commands I needed into our own xxx-ipmi-oem.
Thank you.
Regards,
Chris Chen
________________________________
寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Chris Chen (TPI) <Chris.Chen3@flex.com>
寄件日期: 2021年9月7日 上午 08:35
收件者: Andrei Kartashev <a.kartashev@yadro.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hi Anrdrei,
Thank you for your helpful comments.
Regards,
Chris Chen
________________________________
寄件者: Andrei Kartashev <a.kartashev@yadro.com>
寄件日期: 2021年9月6日 下午 06:15
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
Hello,
I don't represent Intel, but have some considerations about this topic:
1) Try to not reuse intel-ipmi-oem. Much better solution would be to
create your own xxx-ipmi-oem package and implement only methods you
really need.
2) Better way would be to implement required logic in phosphor-host-
ipmid and submit changes there. I didn't investigate this yet since we
also pull intel-ipmi-oem to our project, but I believe, it should not
be too difficult. Don't repeat our mistakes ).
3) There is priority argument which you can use to determine handler
call order.
4) Most functions there are specific for Intel servers, so the useless
even is you use Intel CPUs but your own platform.
5) Use "journalctl -t ipmid -o pretty-json" or something like this. But
now it is recommended to use new syntax:
https://urldefense.com/v3/__https://github.com/openbmc/phosphor-logging/blob/master/docs/structured-logging.md__;!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6cseru6Bcw$
On Mon, 2021-09-06 at 09:40 +0000, Chris Chen (TPI) wrote:
> Hi all,
>
> 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.
>
> Thank you.
>
> Regards,
> Chris Chen
>
> 寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表
> Chris Chen (TPI) <Chris.Chen3@flex.com>
> 寄件日期: 2021年9月2日 下午 06:34
> 收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> 主旨: [phosphor-host-ipmid] Questions about IPMI (OEM) command
> development
> Hi all,
>
> 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.
> 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?
> 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?
> 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?
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD
> CPU?
> 5. How to print the "entry("SENDER=%s", sender.c_str())" parts? I
> mean I for now can print out "Set up ipmi context" string after
> following the instruction listed in
> "https://urldefense.com/v3/__https://github.com/openbmc/openbmc/wiki/Debugging-OpenBMC*enabling-application-debug__;Iw!!HSntlCg!G61XcVxUr8Hli8HqIlebVYji3tTPXsn33W5oyo-FlU8fbm6Zd66S0H6csVZtHYM2$
> ", but I don't see "SENDER=" when I executed "journalctl -t ipmid"
> command.
> 6. 1. log<level::DEBUG>("Set up ipmi
> context",entry("SENDER=%s",sender.c_str()),
> entry("NETFN=0x%X", netFn),entry("LUN=0x%X", lun),
> entry("CMD=0x%X", cmd),entry("CHANNEL=%u", channel),
> entry("USERID=%u", userId),
> entry("SESSIONID=0x%X", sessionId),
> entry("PRIVILEGE=%u",static_cast<uint8_t>(privilege)),
> entry("RQSA=%x", rqSA));
> Thank you.
>
> Regards,
> Chris Chen
> Legal Disclaimer :
> The information contained in this message may be privileged and
> confidential.
> It is intended to be read only by the individual or entity to whom it
> is addressed
> or by their designee. If the reader of this message is not the intended
> recipient,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of
> this message!
--
Best regards,
Andrei Kartashev
[-- Attachment #2: Type: text/html, Size: 11770 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-06 9:40 ` 回覆: " Chris Chen (TPI)
2021-09-06 10:03 ` Troy Lee
2021-09-06 10:15 ` Andrei Kartashev
@ 2021-09-09 20:15 ` Vernon Mauery
2021-09-11 3:56 ` 回覆: " Chris Chen (TPI)
2 siblings, 1 reply; 12+ messages in thread
From: Vernon Mauery @ 2021-09-09 20:15 UTC (permalink / raw)
To: Chris Chen (TPI); +Cc: openbmc
On 06-Sep-2021 09:40 AM, Chris Chen (TPI) wrote:
>Hi all,
>
>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.
Thanks for being persistent :)
>
>Hi all,
>
>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.
>
> 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?
First some common language:
1) xxx-ipmi-oem is an IPMI provider library. It doesn't need to be
called xxx-ipmi-oem, but that is just a convenient naming convention.
2) whitelist (prefer allowlist) is one kind of filter. Filters are
registered like command handlers, with a priority. Filters can do more
than just block or allow the commands coming in. The filter is passed
the request and can do anything it wants before passing it on. Logging,
mangling, blocking, etc.
It depends on a lot of things. Maybe yes, create a new repo? More
discussion below.
> 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?
There is not a method to remove them, but you can filter them as you
suggested. Also, if you want to add a different implementation (from a
different IPMI provider library) at a higher priority, only the higher
priority implementation will be used.
> 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?
You can have as many IPMI provider libraries on the BMC as needed.
The filtering mechanism does not discriminate between the provider, it
is used at execution time when a command comes in. Every command is
passed to each filter
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
IANAL, but, yes. It is open source and the license does not make that
restriction. It might look kind of weird though :)
If you like all the IPMI functions implemented by the intel-ipmi-oem, it
is fine to use it as is. If there are things you want to change, there
are different ways to go about it.
Here are a couple of scenarios with some options:
1) You like the behavior of an IPMI provider library, but want some
changes. Talk with the owner and see if you can come to some consensus
that works for everyone. This is the most opensource,
community-building, good-will behavior of all. Submit a change and see
if you can get it merged.
2) You like all the IPMI commands in an IPMI provider library except for
one or two. If you want to own the work to keep a patch up to date, it
is possible to just add a bbappend and a patch to modify the code prior
to building. This is okay, but maybe not as ideal. It may end up with a
smaller image size than adding a new provider library to overload the
command implementation.
3) You like all the IPMI commands in an IPMI provider library except for
one or two. You can create a new IPMI provider library for your
organization that can filter out and/or provide overloads for any
existing implementation of IPMI commands from any number of other IPMI
providers.
4) You only like some bits of another IPMI provider. You may be best off
to just copy those bits into a new IPMI provider library of your own,
add your own other OEM commands and/or implementations and carry on.
Really, none of the 'solutions' are ideal, but we are trying to make
trade-offs here that allow individual contributing organizations freedom
to implement OEM commands as they wish without any one organization
being a gatekeeper.
--Vernon
^ permalink raw reply [flat|nested] 12+ messages in thread
* 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-09 20:15 ` Vernon Mauery
@ 2021-09-11 3:56 ` Chris Chen (TPI)
2021-09-15 2:35 ` Vernon Mauery
0 siblings, 1 reply; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-11 3:56 UTC (permalink / raw)
To: Vernon Mauery; +Cc: openbmc
[-- Attachment #1: Type: text/plain, Size: 6127 bytes --]
Hi Vernon,
Thanks for your detailed explanation, I got a lot of concepts from it and realized how should I carry on next.
However, I'm not sure whether my understanding of the filter is correct, so would like to confirm with you further.
* If I for now have 3 IPMI provider libraries, such as the original library in "phosphor-host-ipmid", "intel-ipmi-oem" 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?
* 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?
Regards,
Chris Chen
________________________________
寄件者: Vernon Mauery <vernon.mauery@linux.intel.com>
寄件日期: 2021年9月10日 上午 04:15
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>
副本: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
On 06-Sep-2021 09:40 AM, Chris Chen (TPI) wrote:
>Hi all,
>
>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.
Thanks for being persistent :)
>
>Hi all,
>
>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.
>
> 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?
First some common language:
1) xxx-ipmi-oem is an IPMI provider library. It doesn't need to be
called xxx-ipmi-oem, but that is just a convenient naming convention.
2) whitelist (prefer allowlist) is one kind of filter. Filters are
registered like command handlers, with a priority. Filters can do more
than just block or allow the commands coming in. The filter is passed
the request and can do anything it wants before passing it on. Logging,
mangling, blocking, etc.
It depends on a lot of things. Maybe yes, create a new repo? More
discussion below.
> 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?
There is not a method to remove them, but you can filter them as you
suggested. Also, if you want to add a different implementation (from a
different IPMI provider library) at a higher priority, only the higher
priority implementation will be used.
> 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?
You can have as many IPMI provider libraries on the BMC as needed.
The filtering mechanism does not discriminate between the provider, it
is used at execution time when a command comes in. Every command is
passed to each filter
> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
IANAL, but, yes. It is open source and the license does not make that
restriction. It might look kind of weird though :)
If you like all the IPMI functions implemented by the intel-ipmi-oem, it
is fine to use it as is. If there are things you want to change, there
are different ways to go about it.
Here are a couple of scenarios with some options:
1) You like the behavior of an IPMI provider library, but want some
changes. Talk with the owner and see if you can come to some consensus
that works for everyone. This is the most opensource,
community-building, good-will behavior of all. Submit a change and see
if you can get it merged.
2) You like all the IPMI commands in an IPMI provider library except for
one or two. If you want to own the work to keep a patch up to date, it
is possible to just add a bbappend and a patch to modify the code prior
to building. This is okay, but maybe not as ideal. It may end up with a
smaller image size than adding a new provider library to overload the
command implementation.
3) You like all the IPMI commands in an IPMI provider library except for
one or two. You can create a new IPMI provider library for your
organization that can filter out and/or provide overloads for any
existing implementation of IPMI commands from any number of other IPMI
providers.
4) You only like some bits of another IPMI provider. You may be best off
to just copy those bits into a new IPMI provider library of your own,
add your own other OEM commands and/or implementations and carry on.
Really, none of the 'solutions' are ideal, but we are trying to make
trade-offs here that allow individual contributing organizations freedom
to implement OEM commands as they wish without any one organization
being a gatekeeper.
--Vernon
Legal Disclaimer :
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is addressed
or by their designee. If the reader of this message is not the intended recipient,
you are on notice that any distribution of this message, in any form,
is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this message!
[-- Attachment #2: Type: text/html, Size: 8401 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-11 3:56 ` 回覆: " Chris Chen (TPI)
@ 2021-09-15 2:35 ` Vernon Mauery
2021-09-17 0:13 ` Chris Chen (TPI)
0 siblings, 1 reply; 12+ messages in thread
From: Vernon Mauery @ 2021-09-15 2:35 UTC (permalink / raw)
To: Chris Chen (TPI); +Cc: openbmc
On 11-Sep-2021 03:56 AM, Chris Chen (TPI) wrote:
>Hi Vernon,
>
>Thanks for your detailed explanation, I got a lot of concepts from it and realized how should I carry on next.
>
>However, I'm not sure whether my understanding of the filter is correct, so would like to confirm with you further.
>
>
> * If I for now have 3 IPMI provider libraries, such as the original library in "phosphor-host-ipmid", "intel-ipmi-oem" 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?
There is an option to disable the built-in phosphor-host-ipmid filter.
The one that ships with intel-ipmi-oem was added by Intel to replace the
built-in filter for Intel builds. If the intel-ipmi-oem filter does not
work for you, but you still want the rest of the provider commands, you
might consider adding a patch to your layer that removes the filter so
you can create your own.
The filters must all return OK (0) for the command to get executed. They
will each be run in priority order, but if any of them return non-zero,
then the command will not get executed.
> * 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?
You would need to make sure that all of the filters are returning OK or
the command will not get executed.
>Regards,
>Chris Chen
>
>________________________________
>寄件者: Vernon Mauery <vernon.mauery@linux.intel.com>
>寄件日期: 2021年9月10日 上午 04:15
>收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>
>副本: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
>主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
>
>On 06-Sep-2021 09:40 AM, Chris Chen (TPI) wrote:
>>Hi all,
>>
>>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.
>
>Thanks for being persistent :)
>
>>
>>Hi all,
>>
>>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.
>>
>> 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?
>
>First some common language:
>1) xxx-ipmi-oem is an IPMI provider library. It doesn't need to be
>called xxx-ipmi-oem, but that is just a convenient naming convention.
>2) whitelist (prefer allowlist) is one kind of filter. Filters are
>registered like command handlers, with a priority. Filters can do more
>than just block or allow the commands coming in. The filter is passed
>the request and can do anything it wants before passing it on. Logging,
>mangling, blocking, etc.
>
>It depends on a lot of things. Maybe yes, create a new repo? More
>discussion below.
>
>> 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?
>
>There is not a method to remove them, but you can filter them as you
>suggested. Also, if you want to add a different implementation (from a
>different IPMI provider library) at a higher priority, only the higher
>priority implementation will be used.
>
>> 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?
>
>You can have as many IPMI provider libraries on the BMC as needed.
>
>The filtering mechanism does not discriminate between the provider, it
>is used at execution time when a command comes in. Every command is
>passed to each filter
>
>> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
>
>IANAL, but, yes. It is open source and the license does not make that
>restriction. It might look kind of weird though :)
>
>If you like all the IPMI functions implemented by the intel-ipmi-oem, it
>is fine to use it as is. If there are things you want to change, there
>are different ways to go about it.
>
>Here are a couple of scenarios with some options:
>1) You like the behavior of an IPMI provider library, but want some
>changes. Talk with the owner and see if you can come to some consensus
>that works for everyone. This is the most opensource,
>community-building, good-will behavior of all. Submit a change and see
>if you can get it merged.
>
>2) You like all the IPMI commands in an IPMI provider library except for
>one or two. If you want to own the work to keep a patch up to date, it
>is possible to just add a bbappend and a patch to modify the code prior
>to building. This is okay, but maybe not as ideal. It may end up with a
>smaller image size than adding a new provider library to overload the
>command implementation.
>
>3) You like all the IPMI commands in an IPMI provider library except for
>one or two. You can create a new IPMI provider library for your
>organization that can filter out and/or provide overloads for any
>existing implementation of IPMI commands from any number of other IPMI
>providers.
>
>4) You only like some bits of another IPMI provider. You may be best off
>to just copy those bits into a new IPMI provider library of your own,
>add your own other OEM commands and/or implementations and carry on.
>
>Really, none of the 'solutions' are ideal, but we are trying to make
>trade-offs here that allow individual contributing organizations freedom
>to implement OEM commands as they wish without any one organization
>being a gatekeeper.
>
>--Vernon
>
>Legal Disclaimer :
>The information contained in this message may be privileged and confidential.
>It is intended to be read only by the individual or entity to whom it is addressed
>or by their designee. If the reader of this message is not the intended recipient,
>you are on notice that any distribution of this message, in any form,
>is strictly prohibited. If you have received this message in error,
>please immediately notify the sender and delete or destroy any copy of this message!
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
2021-09-15 2:35 ` Vernon Mauery
@ 2021-09-17 0:13 ` Chris Chen (TPI)
0 siblings, 0 replies; 12+ messages in thread
From: Chris Chen (TPI) @ 2021-09-17 0:13 UTC (permalink / raw)
To: Vernon Mauery; +Cc: openbmc
Hi Vernon,
Got it. Thank you.
Regards,
Chris Chen
-----Original Message-----
From: Vernon Mauery <vernon.mauery@linux.intel.com>
Sent: Wednesday, September 15, 2021 10:35 AM
To: Chris Chen (TPI) <Chris.Chen3@flex.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: 回覆: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command development
On 11-Sep-2021 03:56 AM, Chris Chen (TPI) wrote:
>Hi Vernon,
>
>Thanks for your detailed explanation, I got a lot of concepts from it and realized how should I carry on next.
>
>However, I'm not sure whether my understanding of the filter is correct, so would like to confirm with you further.
>
>
> * If I for now have 3 IPMI provider libraries, such as the original library in "phosphor-host-ipmid", "intel-ipmi-oem" 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?
There is an option to disable the built-in phosphor-host-ipmid filter.
The one that ships with intel-ipmi-oem was added by Intel to replace the built-in filter for Intel builds. If the intel-ipmi-oem filter does not work for you, but you still want the rest of the provider commands, you might consider adding a patch to your layer that removes the filter so you can create your own.
The filters must all return OK (0) for the command to get executed. They will each be run in priority order, but if any of them return non-zero, then the command will not get executed.
> * 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?
You would need to make sure that all of the filters are returning OK or the command will not get executed.
>Regards,
>Chris Chen
>
>________________________________
>寄件者: Vernon Mauery <vernon.mauery@linux.intel.com>
>寄件日期: 2021年9月10日 上午 04:15
>收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>
>副本: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
>主旨: Re: 回覆: [phosphor-host-ipmid] Questions about IPMI (OEM) command
>development
>
>On 06-Sep-2021 09:40 AM, Chris Chen (TPI) wrote:
>>Hi all,
>>
>>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.
>
>Thanks for being persistent :)
>
>>
>>Hi all,
>>
>>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.
>>
>> 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?
>
>First some common language:
>1) xxx-ipmi-oem is an IPMI provider library. It doesn't need to be
>called xxx-ipmi-oem, but that is just a convenient naming convention.
>2) whitelist (prefer allowlist) is one kind of filter. Filters are
>registered like command handlers, with a priority. Filters can do more
>than just block or allow the commands coming in. The filter is passed
>the request and can do anything it wants before passing it on. Logging,
>mangling, blocking, etc.
>
>It depends on a lot of things. Maybe yes, create a new repo? More
>discussion below.
>
>> 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?
>
>There is not a method to remove them, but you can filter them as you
>suggested. Also, if you want to add a different implementation (from a
>different IPMI provider library) at a higher priority, only the higher
>priority implementation will be used.
>
>> 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?
>
>You can have as many IPMI provider libraries on the BMC as needed.
>
>The filtering mechanism does not discriminate between the provider, it
>is used at execution time when a command comes in. Every command is
>passed to each filter
>
>> 4. Am I able to use "intel-ipmi-oem" on a platform that is using AMD CPU?
>
>IANAL, but, yes. It is open source and the license does not make that
>restriction. It might look kind of weird though :)
>
>If you like all the IPMI functions implemented by the intel-ipmi-oem,
>it is fine to use it as is. If there are things you want to change,
>there are different ways to go about it.
>
>Here are a couple of scenarios with some options:
>1) You like the behavior of an IPMI provider library, but want some
>changes. Talk with the owner and see if you can come to some consensus
>that works for everyone. This is the most opensource,
>community-building, good-will behavior of all. Submit a change and see
>if you can get it merged.
>
>2) You like all the IPMI commands in an IPMI provider library except
>for one or two. If you want to own the work to keep a patch up to date,
>it is possible to just add a bbappend and a patch to modify the code
>prior to building. This is okay, but maybe not as ideal. It may end up
>with a smaller image size than adding a new provider library to
>overload the command implementation.
>
>3) You like all the IPMI commands in an IPMI provider library except
>for one or two. You can create a new IPMI provider library for your
>organization that can filter out and/or provide overloads for any
>existing implementation of IPMI commands from any number of other IPMI
>providers.
>
>4) You only like some bits of another IPMI provider. You may be best
>off to just copy those bits into a new IPMI provider library of your
>own, add your own other OEM commands and/or implementations and carry on.
>
>Really, none of the 'solutions' are ideal, but we are trying to make
>trade-offs here that allow individual contributing organizations
>freedom to implement OEM commands as they wish without any one
>organization being a gatekeeper.
>
>--Vernon
>
>Legal Disclaimer :
>The information contained in this message may be privileged and confidential.
>It is intended to be read only by the individual or entity to whom it
>is addressed or by their designee. If the reader of this message is not
>the intended recipient, you are on notice that any distribution of this
>message, in any form, is strictly prohibited. If you have received this
>message in error, please immediately notify the sender and delete or destroy any copy of this message!
^ permalink raw reply [flat|nested] 12+ messages in thread