OMI 1.0.6 Release Notes
=======================
This short document describes changes from OMI-1.0.5 to OMI-1.0.6. Each change
is described in a section below.
1. Provider may now post CIM_Error:
===================================
OMI-1.0.6 now supports providers that post errors that are represented by
the CIM_Error class. Providers may post CIM_Error instances directly by
calling:
MI_Result MI_CALL MI_Context_PostCimError(
_In_ MI_Context* context,
_In_ const MI_Instance *error);
The use this function, the provider developer must generate the CIM_Error
class using the -e option (extra class option). For example:
$ omigen schema.mof -e CIM_Error ...
To use MI_Context_PostCimError(), the provider should include "CIM_Error.h".
Alternatively, the provider can post a CIM_Error indirectly, without generating
CIM_Error. This is done by calling the following function.
MI_Result MI_CALL MI_Context_PostError(
_In_ MI_Context* context,
MI_Uint32 resultCode,
_In_z_ const MI_Char* resultType,
_In_z_ const MI_Char* errorMessage);
This function implicitly creates an instance of CIM_Error (based on these
parameters) and sends it to the client. If the 'resultType' parameter is equal
to MI_RESULT_TYPE_MI ("MI"), then CIM_Error.CIMStatusCode is set from the
'resultCode' parameter (given by the MI_Result enumeration). Else,
CIM_Error.CIMStatusCode is set to MI_RESULT_FAILED.
Currently, OMI only supports delivery of CIM_Error information to the client.
2. Configuring and building outside the source directory:
=========================================================
With OMI-1.0.5 it was only possible to configure and build within the source
tree. This meant writing the build output into the source tree under a
directory called './output/HOSTNAME' (where HOSTNAME was the name of the
host on which OMI is built).
With OMI-1.0.6, it is now possible to configure and build outside of the source
directory (of course configuring and building inside the source tree is still
supported). To take an example, suppose the source distribution resides here.
/home/jdoe/omi-1.0.6
And suppose that one creates a 'build' directory named:
/home/jdoe/build
Then OMI may be built from /home/jdoe/build as follows.
$ cd /home/jdoe/build
$ ../omi-1.0.6/configure
$ make
All build output files are placed into this directory:
/home/jdoe/build/output
Notice that the HOSTNAME directory no longer is needed since distinct build
directories can be used for each build.
3. Improved build scripts for cross-complier environments:
==========================================================
It is now easier to configure and build OMI with a cross-compiler. To achieve
this, the following option was removed from 'configure':
--toolchain=PATH
Instead, individual options were added to locate components and define build
parameters. These include:
--with-cc=PATH
--with-cxx=PATH
--with-ar=PATH
--openssl=PATH
--opensslcflags=FLAGS
--openssllibs=FLAGS
--openssllibdir=PATH
Please see './configure --help' for details on each. Now it is possible to
specifiy the exact location of each component.
In general, one uses the --target option to configure and build for a
cross-compiler. For example:
./configure --target=MONTAVISTA_IX86_GNU
Additional options are required to specify the location of the cross-compiler
components. So to run configure, one might have something like this:
./configure
--target=NETBSD_IX86_GNU
--with-cc=/opt/toolchain/bin/586-gcc
--with-cxx=/opt/toolchain/bin/586-g++
--with-ar=/opt/toolchain/bin/586-ar
--opensslcflags="-I /opt/toolchain/include"
--openssllibdir=/opt/toolchain/lib64
--openssllibs="-L/opt/toolchain/lib64 -lssl -lcrypto"
4. Added NETBSD_IX86_GNU target:
================================
OMI-1.0.6 adds the The following experimental build target:
NETBSD_IX86_GNU
This target is for a 32-bit NetBSD platform running the GNU toolchain. It
is experimental and so far is just a placeholder to porting to NetBSD.
4. Fixed bug that prevented "omicli iv" from passing arrays of references:
==========================================================================
OMI-1.0.6 fixes a bug with the "omicli iv" subcommand that prevented it from
passing arrays of references as parameters. Consider the following example:
$ omicli iv test/cpp { X_Dog } Fight { CatsIn [ { X_Cat Key 1001 } ] }
The following Parameter expression defines an array of references:
CatsIn [ { X_Cat Key 1001 } ]
This is encoded as an array of instances of X_Cat and sent to the server.
Before this is passed to the provider, the provider manager converts it to
an array of references. This now works correctly.
5. New --no-warnings option (-W option removed):
================================================
The -W option (which enabled warnings) has been removed from omigen. Now
warnings are printed by default. The --no-warnings option has been added
to suppress warnings.
6. New omigen warning about non-association classes with references:
====================================================================
The omigen command now warns about non-association classes that have
references. Here is an example of such a class.
class XYZ_Connector
{
[Key] XYZ_Gadget REF Left;
[Key] XYZ_Connector REF Right;
};
This class is illegal according the the DMTF CIM infrastructure specification
since it has references but does not bear the Association qualifier.
6. New omigen warning about classes with no schema prefix:
==========================================================
The omigen command now warns about class names with no schema prefix. For
example, the following is illegal:
class MyClass
{
...
};
The CIM infrastructure specification says that all classes must be preceded by
a schema name followed by an underscore. For example, the following is legal:
class XYZ_MyClass
{
...
};
7. Removed inclusion of <common.h> from <micxx/datetime.h>:
===========================================================
The C++ header file <micxx/datetime.h> erroneously included <common.h> which
is not part of the installed environment. This caused errors while compiling
C++ providers. This is fixed in OMI-1.0.6.
You are here:
