On Tuesday 08 November 2016 01:55 AM, Brendan Higgins wrote:
Sharing the provider libraries makes sense; my first area of concern is the API; I am currently working on a change to the API (see https://gerrit.openbmc-project.xyz/#/c/841/ for details); I would prefer you do not make any changes to the current API, but understand if the need arises before my change is ready.
From what i have noticed in the patch, there is support for ipmid_callback_t handlers  as it is now. So the change in API is to accommodate the OEM group ?
So do you have plans to change the callback signatures for the standard commands already implemented in host-ipmid?


Could you elaborate on how you plan on enforcing privilege? Having each provider check privilege level seems like a leaky abstraction to me; I think it would make more sense to have privilege managed by the host-ipmid and the net-ipmid.
Table G - Command Number Assignments and Privilege Levels in the IPMI specification gives more details on this.

Each command is assigned a privilege level( Callback, User, Operator, Admin) which means that the command can be executed only on a session with this privilege or higher.
So if a command needs be executed on net-ipmid path, one of the attribute needed for net-ipmid is the command's privilege level.
The privilege provided by each command is a registration parameter and it is consumed only by net-ipmid.

As part of the same issue, i am separating commands that need to be executed from system interface as a separate library.

The provider libraries is now copied into /usr/lib/host-ipmid. The plan is to have the /usr/lib/ipmid-providers as the default install location for all providers
and then symlink into /usr/lib/host-ipmid and /usr/lib/net-ipmid depending on whether the provider library is needed in out-of-band or in-band path.

As far as the actual details concerning phosphor-net-ipmid: I do not have strong opinions on the matter as Google has no intention of using IPMI over LAN at this time, but would welcome discussion on the matter nonetheless.

Cheers