From: tomjose <tomjose@linux.vnet.ibm.com>
To: Brendan Higgins <brendanhiggins@google.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Discussion on IPMI provider libraries
Date: Tue, 8 Nov 2016 15:39:13 +0530 [thread overview]
Message-ID: <5821A449.3020807@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAFd5g45JxpeYZiq3inm0JkKeyQjk7T_4uARLY=Anf9EHXymhBQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
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/
> <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
[-- Attachment #2: Type: text/html, Size: 3881 bytes --]
next prev parent reply other threads:[~2016-11-08 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 13:43 Discussion on IPMI provider libraries tomjose
2016-11-07 20:25 ` Brendan Higgins
2016-11-08 10:09 ` tomjose [this message]
2016-11-14 23:59 ` Brendan Higgins
2016-11-15 10:58 ` Patrick Williams
2016-11-16 7:00 ` tomjose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5821A449.3020807@linux.vnet.ibm.com \
--to=tomjose@linux.vnet.ibm.com \
--cc=brendanhiggins@google.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.