D-bus model proposal for pay for access features
proclivis at gmail.com
Wed May 5 00:21:53 AEST 2021
I am not qualified to comment on “how”, but I see value in a BMC that can license features. However, it should cover both hardware and firmware. I can imagine licensed algorithms implemented as firmware.
Given that a licensed feature might impact availability of information via gui or service, it must support queries for availability so services can behave properly when enabled and disabled.
Sent from my iPad
> On May 4, 2021, at 1:43 AM, Ratan Gupta <ratankgupta31 at gmail.com> wrote:
> Hi Team,
> Any comments on the below proposal?
>> On Fri, Apr 30, 2021 at 11:45 PM Ratan Gupta <ratankgupta31 at gmail.com> wrote:
>> 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 are
>> In 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc