All of lore.kernel.org
 help / color / mirror / Atom feed
* Feedback on Current OpenBMC and Proposing Some Improvements
@ 2020-06-18 21:25 Alex Qiu
  2020-06-18 21:40 ` Alex Qiu
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Qiu @ 2020-06-18 21:25 UTC (permalink / raw)
  To: openbmc
  Cc: Kais Belgaied, Peter Lundgren, Josh Lehan, Ofer Yehielli,
	Richard Hanley, Benjamin Fair, Robert Lippert, Kun Yi,
	gBMC Discussions, Nancy Yuen

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Hi OpenBMC community,

It has been a while since Google has adopted the dynamic software stack of
OpenBMC, namely using entity-manager for FRU discovery, dbus-sensors for
sensor reading, and intel-ipmi-oem for IPMI command handling. We discovered
issues and limitations with this dynamic software stack along the way, so
I’m proposing some ideas on how OpenBMC may improve, which may lead to
detailed designs about it. Let me call it "Improvements" in this email per
say. I think the highlight of these ideas are: 1) having a robust framework
to handle hardware topology, and 2) having accommodations for code to
intervene on varieties of BMC tasks.


I'll split the content of this topic into two additional emails for easier
digestion: 1) Difficulties and Issue Examples; 2) "Improvements" Ideas. The
main discussion may still stay in this thread.


Since this is a big architectural change compared to the existing dynamic
software stack, I would like to hear feedback or review on the conceptual
ideas before we turn these ideas into more concrete designs or prototypes.
On the other hand, there is a high probability that I didn’t express my
idea well enough to understand, and there may be a language barrier to get
over. I’ll try to see if I can use some code to make a tiny prototype to
illustrate the ideas better at some point. Thank you!


- Alex Qiu

[-- Attachment #2: Type: text/html, Size: 3913 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Feedback on Current OpenBMC and Proposing Some Improvements
  2020-06-18 21:25 Feedback on Current OpenBMC and Proposing Some Improvements Alex Qiu
@ 2020-06-18 21:40 ` Alex Qiu
  2020-06-20  0:38   ` Alex Qiu
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Qiu @ 2020-06-18 21:40 UTC (permalink / raw)
  To: OpenBMC Maillist
  Cc: Kais Belgaied, Peter Lundgren, Josh Lehan, Ofer Yehielli,
	Richard Hanley, Benjamin Fair, Robert Lippert, Kun Yi,
	gBMC Discussions, Nancy Yuen

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

Just sent out the additional email threads. You can also find them in these
links:

Feedback on Current OpenBMC and Proposing Some Improvements ----
Difficulties and Issue Examples:
https://lists.ozlabs.org/pipermail/openbmc/2020-June/022065.html

Feedback on Current OpenBMC and Proposing Some Improvements ----
"Improvements" Ideas:
https://lists.ozlabs.org/pipermail/openbmc/2020-June/022067.html

Thank you!

- Alex Qiu


On Thu, Jun 18, 2020 at 2:25 PM Alex Qiu <xqiu@google.com> wrote:

> Hi OpenBMC community,
>
> It has been a while since Google has adopted the dynamic software stack of
> OpenBMC, namely using entity-manager for FRU discovery, dbus-sensors for
> sensor reading, and intel-ipmi-oem for IPMI command handling. We discovered
> issues and limitations with this dynamic software stack along the way, so
> I’m proposing some ideas on how OpenBMC may improve, which may lead to
> detailed designs about it. Let me call it "Improvements" in this email per
> say. I think the highlight of these ideas are: 1) having a robust framework
> to handle hardware topology, and 2) having accommodations for code to
> intervene on varieties of BMC tasks.
>
>
> I'll split the content of this topic into two additional emails for easier
> digestion: 1) Difficulties and Issue Examples; 2) "Improvements" Ideas. The
> main discussion may still stay in this thread.
>
>
> Since this is a big architectural change compared to the existing dynamic
> software stack, I would like to hear feedback or review on the conceptual
> ideas before we turn these ideas into more concrete designs or prototypes.
> On the other hand, there is a high probability that I didn’t express my
> idea well enough to understand, and there may be a language barrier to get
> over. I’ll try to see if I can use some code to make a tiny prototype to
> illustrate the ideas better at some point. Thank you!
>
>
> - Alex Qiu
>

[-- Attachment #2: Type: text/html, Size: 5077 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Feedback on Current OpenBMC and Proposing Some Improvements
  2020-06-18 21:40 ` Alex Qiu
@ 2020-06-20  0:38   ` Alex Qiu
  0 siblings, 0 replies; 3+ messages in thread
From: Alex Qiu @ 2020-06-20  0:38 UTC (permalink / raw)
  To: OpenBMC Maillist
  Cc: Kais Belgaied, Peter Lundgren, Josh Lehan, Ofer Yehielli,
	Richard Hanley, Benjamin Fair, Robert Lippert, Kun Yi,
	gBMC Discussions, Nancy Yuen

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

As promised, I made a runnable Python 3 demo to illustrate my ideas:
https://github.com/alex310110/bmc-proto-20q2

Thank you!

- Alex Qiu


On Thu, Jun 18, 2020 at 2:40 PM Alex Qiu <xqiu@google.com> wrote:

> Just sent out the additional email threads. You can also find them in
> these links:
>
> Feedback on Current OpenBMC and Proposing Some Improvements ----
> Difficulties and Issue Examples:
> https://lists.ozlabs.org/pipermail/openbmc/2020-June/022065.html
>
> Feedback on Current OpenBMC and Proposing Some Improvements ----
> "Improvements" Ideas:
> https://lists.ozlabs.org/pipermail/openbmc/2020-June/022067.html
>
> Thank you!
>
> - Alex Qiu
>
>
> On Thu, Jun 18, 2020 at 2:25 PM Alex Qiu <xqiu@google.com> wrote:
>
>> Hi OpenBMC community,
>>
>> It has been a while since Google has adopted the dynamic software stack
>> of OpenBMC, namely using entity-manager for FRU discovery, dbus-sensors for
>> sensor reading, and intel-ipmi-oem for IPMI command handling. We discovered
>> issues and limitations with this dynamic software stack along the way, so
>> I’m proposing some ideas on how OpenBMC may improve, which may lead to
>> detailed designs about it. Let me call it "Improvements" in this email per
>> say. I think the highlight of these ideas are: 1) having a robust framework
>> to handle hardware topology, and 2) having accommodations for code to
>> intervene on varieties of BMC tasks.
>>
>>
>> I'll split the content of this topic into two additional emails for
>> easier digestion: 1) Difficulties and Issue Examples; 2) "Improvements"
>> Ideas. The main discussion may still stay in this thread.
>>
>>
>> Since this is a big architectural change compared to the existing dynamic
>> software stack, I would like to hear feedback or review on the conceptual
>> ideas before we turn these ideas into more concrete designs or prototypes.
>> On the other hand, there is a high probability that I didn’t express my
>> idea well enough to understand, and there may be a language barrier to get
>> over. I’ll try to see if I can use some code to make a tiny prototype to
>> illustrate the ideas better at some point. Thank you!
>>
>>
>> - Alex Qiu
>>
>

[-- Attachment #2: Type: text/html, Size: 5826 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-20  0:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-18 21:25 Feedback on Current OpenBMC and Proposing Some Improvements Alex Qiu
2020-06-18 21:40 ` Alex Qiu
2020-06-20  0:38   ` Alex Qiu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.