Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


This README file is an extract of the oficial manual and other
sources of information related with konkret tool set.

As the manual says there are four ways to use KonkretCMPI:

1. Convenience functions that make working with CMPI easier. 
2. Default operation functions that implement many of the provider operations
3. Concrete CIM class interfaces from MOF definitions. It generates headers 
which contains a C structure definition classes and functions for manipulating 
the object defined in the MOF structure.
4. Can generate provider skeletons automatically.

Developers using KonkretCMPI have several advantages. It generates concrete 
type-safe C interfaces for manipulating CIM elements. Provides complete 
default implementations for many provider operations. Supplies convenience 
functions for working with CMPI. It generates the initial CMPI provider 
skeletons from MOF (Managed Object Format). It builds on CMPI rather than 
introducing a new provider interface. It does not impose run-time library 
dependencies. The footprint of the providers produces is small. Also the 
development effort is greatly reduced. 

Writing a typical provider module consists of creating two C source files and 
one C header file.  These files are compiled and built into a single shared 
object (Linux) that encompasses the functionality of the provider.  The first C 
source file represents the physical provider.  It contains an entry point into 
the provider that the CIMOM uses when dynamically loading the provider.  
Essentially, this class simply creates and returns a new instance of a logical 

Example: Creating a complete CIM Provider skeleton from MOF file.

$ cat Widget.mof
class KC_Widget
    	string Id;
    	string Color;
    	uint32 Size;

    	uint32 Add(uint32 X, uint32 Y);

$ konkret -s KC_Widget -m Widget.mof KC_Widget=Widget

- This command generates the skeleton for all operations
and methods:

	Widget.h – contains the Widget class interfaces.
	WidgetProvider.c – contains the Widget provider skeleton.

- Let's inspect the contents of this files:

Wigdet.h: It containsts three sorts of definitions:

	- Widget structure and associated functions.
	- The WidgetRef structure and associated functions.
	- Extrinsic method prototypes and a function for invoking them.

/* classname=KC_Widget */
typedef struct _Widget
    KBase __base;
    /* KC_Widget features */
    const KString Id;
    const KString Color;
    const KUint32 Size;

- All generated structures contain:

	- The private __base field 
	- One or more fields that either represent CIM properties or CIM 

- Properties always have one of the following types:

KBoolean, KUint8, KSint8, KUint16, KSint16, KUint32, KSint32,
KUint64, KSint64, KReal32, KReal64, KChar16, KString, KDateTime.

Each of these is a structure with the following fields:

exists – indicates whether property exists.
null – indicates whether property is null.
value – contains the current value of the property.
Take for example the KUint32 structure defined below.

     typedef struct _KUint32
         CMPIUint32 exists; -> A non-zero field indicates that the field exists
			       or is present.
         CMPIUint32 null; -> indicates that the given field is null
         CMPIUint32 value; ->  the value of the property itself.

Thats structures of data types exists because of CMPI providers can form 
partial instances with only a subset of the properties specified. KonkretCMPI 
generates special modifier functions for setting these safely. The user must 
use the modifiers and must never modify these fields directly.  

The skeleton (ready to be filled) makes availables this functions:


These are some of functions related with the CMPI specification. These are 
only some of the the group functions specified by the standard, functions 
signatures gruped in:

Instance IM, Association MI, Property MI, Method MI, Indication MI.

Note: In CMPI neutral terminology the CIMON broker is the "Manager Broker (MB)"
, and the CIM Provider is the "Management Instrumentation (MI).

The most of functions are working entities, so we can to complet the 
development cycle with the following steps:

Compiling with CMake:

	$ mkdir build
	$ cmake ..
	$ make

Deploying the CIM provider:

	$ cd src 
	$ su -c "cp libcmpiWidget_Widget.so /usr/lib/cmpi/"

Making the registration file in order to load the provider in the CIMON:

	$ konkretreg libcmpiWidget_Widget.so > libcmpiWidget_Widget.reg

Deploying (registering) the REF and MOF file in SFCB CIMON:

	$ su -c "sfcbstage -r libcmpiWidget_Widget.reg ../../src/Widget.mof"
	$ su -c "sfcbrepos -f"

Reloading the CIMON:

	$ su -c "systemctl reload-or-try-restart sblim-sfcb.service"

Testing the CIM Provider:

	$ test/test_widget.py 1 2
	result: 3
	error: {}

Author: Javi Roman <javiroman@kernel-labs.org>