IPMI Maintainer Call Notes - 2/13/2018

[Emily Shaffer]

Meeting 2/13/2018

Agenda:

Discuss about dynamic addition of SDR’s based on James Feist’s patch.
https://gerrit.openbmc-project.xyz/#/c/8521/
    Basic linear fit to the min/max
    Tom: Not entirely clear on how to fit into current sensors
    Doesn’t use yaml-generated sensor map - polls along DBus instead
    Intel uses JSON/probing to generate DBus interfaces
    Min/max code review in bikeshedding - do we want to back it as maintainers?
    Pros: don’t need to duplicate configs between hwmon/ipmid, don’t
need to calculate m/b/b_exp manually
    Current pros of yaml: DIMMs, CPU info, etc - passed in-band to BMC
from host - host firmware relies on sensor number (at IBM)
        At Intel - baseboard sensors can be probed, add-on cards can
be probed to determine whether to probe for other sensors; json
indicates which FRUs found during probe mean presence of which sensors
- IBM d
oesn’t do FRU probing. JSON has fru-to-sensor mapping
        At Google - not sure, Emily needs to ask
    IBM - MRW defines sensor numbers etc - it’s shared by host & bmc
firmwares - MRW is generated by YAML - elsewhere YAML is handcoded
(like on Zaius)
    Should SDR list represent the state of the system, or the map of
the system - i.e., should an SDR be sent for a sensor which is absent?
Ex: 4-socket CPU with one missing - should 4 SDR entries be sent (with
one not responding to readings?) Yes.  What about for memory?
    Does the probe in the Intel patch generate JSON? No.  JSON
functions similarly to YAML today (but at runtime)
    How to reconcile the Intel patch with existing code? Basically,
define those sensors in YAML but make sure their DBus interfaces
provide min/max - this patch should just work
    Maintainers: please review that patch as though it should be
checked in - wait for James to push it vs. ipmid instead of on its own
in experimental branch
Discuss the future of ipmi callback functions (possibly using fancy
c++ variadic templates to automagically extract request parameters and
pack responses)
    Driven by Vernon, Ed, William - passing buffers & using callbacks
is C, not C++, and very unsafe
    Boost DBus library has a nice DBus registration function using C++
functor/return type, which takes care of everything. Lots of magic at
compile time.  Writing the library kind of sucks but once it’s written
it’s nice to use.  Do we want to invest in something like that for
IPMI?
    Seems like resources would have to be volunteer only.
    Variadic template which can be called in order to register the
callback; can take as many arguments as you want of various types;
compiler decides what to do with each argument.  Lots of generated
code but compiler optimization helps
Background on host-ipmid current state
    Very early module - somewhat prototype code - originally C
    Net-ipmid was written once we had more modern functions
Shared library for host and net IPMI handlers? Some incoming message
handling could be shared if we split into a library - half as much
code to maintain.  How much of it can we separate and still have
host/net make sense on their own?  (Sidebar - should we handle both
channels in the same process?)
Google has allocated someone to sdbusplus refactor (host-ipmid ->
sdbusplus, no more sd-bus.h)
Emily - make another document with priority list that we can track as
maintainers
Vernon expressed an interest in asyncio functionality similar to
boost-dbus appearing in sdbusplus (but it was outside of the scope of
Liz’s refactor work)


-- 
Emily Shaffer