All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ratan Gupta <ratankgupta31@gmail.com>
To: openbmc@lists.ozlabs.org
Subject: D-bus model proposal for pay for access features
Date: Fri, 30 Apr 2021 23:45:00 +0530	[thread overview]
Message-ID: <CAMhqiMoFAHcUk0nO_xoOubcZqF_dPDFweqsttTULRJK38o1Ung@mail.gmail.com> (raw)

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

Hi All,

I would like to introduce a dbus model proposal around pay for access
features.Normally IBM system ships with more hardware than was
purchased, which can be unlocked later.

Features could be 1) AIX enabled/disabled
2) How many processors are enabled
3) How much memory is enabled

*Proposed Model:*

The model consists of following main entities:1 - licenses - these
objects represents the features.  There will be a license represnting
feature(one is to one relation ship) and these objects have state -
active, inactive, unknown, etc.
These objects could implement the Delete interface for when a client
wishes to disable the license/feature.

2 - manager - the manager object (distinct from freedesktop object
manager) provides a method
interface to create new license objects.

*Alternate Dbus Model:*

1 - Licenses: these objects represent an agreement.  These objects have an
association to one or more features, and these objects have state -
active,inactive, unknown, etc.
These objects could implement the Delete interface for when a client
wishes to disable the license.

2 - Features: these objects describe the features available.
Feature objects would be static and implementation/platform defined.
A BMC or host firmware update
could potentially add or remove the available features exposed as dbus
objects.  At the moment the
only feature attribute I can think of is a name and the feature status.

3 Manager - the manager object (distinct from freedesktop object manager)
provides a method interface to create new license objects.

The difference between two models areIn the alternate Dbus model we
are keeping the feature Dbus object and the License have an associated
features
In the proposed model we are only keeping the license D-bus object
which represent the feature.

Flow would be as below with the proposed model -1/ Manager object
would be having interface like upload (License activation key)
2/ On IBM systems we send this key to the host firmware which
activates the features
3/ Host Firmware sends the activated feature list to the BMC
4/ BMC creates the licenses for the activated features

I suspect an implementation of the above flow is highly IBM specific,
but I hope some of you have some feedback that might enable some
collaboration.
If not - where should we put this application?

Ratan

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

             reply	other threads:[~2021-04-30 18:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 18:15 Ratan Gupta [this message]
2021-05-04  7:41 ` D-bus model proposal for pay for access features Ratan Gupta
2021-05-04 14:21   ` Mike Jones
2021-05-04 17:02 ` Ed Tanous
2021-05-04 21:18   ` Mike Jones
2021-05-05  0:00     ` Brad Bishop
2021-05-05  1:16     ` Ed Tanous
2021-05-04 23:38   ` Brad Bishop
2021-05-05 17:36     ` Patrick Williams
2023-10-06  4:51       ` D-bus model proposal for pay for access features - LicenseService at OpenBMC Sunitha Harish
2023-10-06 12:29         ` Patrick Williams
2023-10-06 17:17           ` Brad Bishop
2023-10-06 19:38             ` Patrick Williams
2023-10-13  2:02             ` Andrew Jeffery
2023-10-13  4:13               ` Brad Bishop
2023-10-13  6:02                 ` Sunitha Harish
2023-10-13  6:34                 ` Andrew Jeffery
2023-10-13 16:03                   ` Brad Bishop
2023-10-18  7:21                     ` Sunitha Harish
2023-10-18 13:18                       ` Brad Bishop
2023-10-19 10:26                         ` Sunitha Harish
2023-10-19 10:48                           ` Sunitha Harish
2023-10-20  5:06                           ` Andrew Jeffery
2023-10-20  5:42                             ` Sunitha Harish
2023-10-20  5:57                               ` Abhilash Kollam
2023-10-06 17:55           ` Patrick Williams

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=CAMhqiMoFAHcUk0nO_xoOubcZqF_dPDFweqsttTULRJK38o1Ung@mail.gmail.com \
    --to=ratankgupta31@gmail.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.