All of lore.kernel.org
 help / color / mirror / Atom feed
* BMC version check via restful
@ 2017-11-03  8:14 tao-ching Yu
  2017-11-03 13:37 ` Brad Bishop
  0 siblings, 1 reply; 2+ messages in thread
From: tao-ching Yu @ 2017-11-03  8:14 UTC (permalink / raw)
  To: openbmc; +Cc: anoo

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

Hi Adriana,

I noticed the version of BMC  is under /xyz/openbmc_project/Software/xxxxxxx
But I found that this "xxxxxxxx" is not fixed
ex./xyz/openbmc_project/software/13264da3
or /xyz/openbmc_project/software/aaf838cc
What does this "string" mean? Is this BMC FW related(version)? Could this
string be fixed?
How does user know the right object path and get the right information of
BMC via restful?
Because this object path is not fixed.

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

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

* Re: BMC version check via restful
  2017-11-03  8:14 BMC version check via restful tao-ching Yu
@ 2017-11-03 13:37 ` Brad Bishop
  0 siblings, 0 replies; 2+ messages in thread
From: Brad Bishop @ 2017-11-03 13:37 UTC (permalink / raw)
  To: tao-ching Yu; +Cc: openbmc, anoo


> On Nov 3, 2017, at 4:14 AM, tao-ching Yu <yutaoc1984@gmail.com> wrote:
> 
> Hi Adriana,
> 
> I noticed the version of BMC  is under /xyz/openbmc_project/Software/xxxxxxx
> But I found that this "xxxxxxxx" is not fixed
> ex./xyz/openbmc_project/software/13264da3 or /xyz/openbmc_project/software/aaf838cc
> What does this "string" mean? Is this BMC FW related(version)? Could this string be fixed?
> How does user know the right object path and get the right information of BMC via restful?
> Because this object path is not fixed.
> 
> 

The image identifier is briefly discussed here: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/README.md#image-identifier

As of today, the ID is an implementation detail and there aren’t any requirements on it
at an API level.

Keep in mind that the OpenBMC D-Bus API is first and foremost designed to facilitate
BMC application compatibility, not end user interface standardization.  End user
interface standardization would be accomplished with Redfish, IPMI, etc…

This nuance is often lost because we do happen to have a REST server application that exposes
the internal D-Bus API via REST with little translation.  But ideally that isn’t
the user-interface for a complete BMC implementation.

Can you think of a scenario where adding restrictions on the ID at the D-Bus API level would
enable additional compatibility between on-BMC applications?

-brad

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

end of thread, other threads:[~2017-11-03 13:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-03  8:14 BMC version check via restful tao-ching Yu
2017-11-03 13:37 ` Brad Bishop

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.