All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: Brendan Higgins <brendanhiggins@google.com>
Cc: tomjose <tomjose@linux.vnet.ibm.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Discussion on IPMI provider libraries
Date: Tue, 15 Nov 2016 04:58:07 -0600	[thread overview]
Message-ID: <20161115105807.GJ15757@heinlein.lan> (raw)
In-Reply-To: <CAFd5g46QM8PyrGSFjL2Otq_dLOmCcdELL_-nQh1Th09kPMbYFQ@mail.gmail.com>

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

On Mon, Nov 14, 2016 at 03:59:08PM -0800, Brendan Higgins wrote:
> > The privilege provided by each command is a registration parameter and it
> > is consumed only by net-ipmid.
> 
> 
> That's fine, but in that case it should not go in the callback; it should
> be maintained and enforced by net-ipmid when it looks up a handler.

Neither net-ipmid nor host-ipmid intrinsically know all of the IPMI
commands that will or may be registered.  This is especially true for
OEM commands where the privilege level is determined by the command.

Are the privilege levels defined by the IPMI spec?  If so, I don't see
anything incorrect about each provider having it.  If not, it is
something that we have defined at build time, correct?  Would it be
acceptable to have multiple symlink locations for net-ipmid providers?
ie. /usr/lib/phosphor-net-ipmid/user/ ,
/usr/lib/phosphor-net-ipmid/admin/ , etc.  I suspect we would need to
break libraries up more because currently a single library provides
commands at different privilege levels.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2016-11-15 10:58 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
2016-11-14 23:59     ` Brendan Higgins
2016-11-15 10:58       ` Patrick Williams [this message]
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=20161115105807.GJ15757@heinlein.lan \
    --to=patrick@stwcx.xyz \
    --cc=brendanhiggins@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=tomjose@linux.vnet.ibm.com \
    /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.