Title: The OpenPegasus memory-resident repository Date: 1 November 2007 Reference: PEP 307 Status: Draft Overview of the Memory-Resident Repository The memory-resident repository is an implementation of the OpenPegasus CIM Class and Instance repository that operate completely in memory and was designed to be used primarily by embedded systems. It has the following characteristics. 1. The class repository is read-only and must be built and installed as part of the server startup. There is no capability to add, modify, delete classes or qualifiers once the OpenPegasus server has been built. 2. The instance repository is maintained in core and is fully read/write. The persistence of the instance repository is maintained through a set of callbacks that the system creator must create to save and restore the instance repository. How to Build the Memory-Resident Class Repository Thisepository is built with the Pegasus compiler cimmofl. Note that in the memory-resident repository there is no capability to modify the class repository subsequent to building the system so the complete class repository must be compiled prior to building the system. To build the memory-resident repository, first determine the CIM namespaces to be used and the classes that will be included in each namespace. The complete set of classes and qualifiers for a single namespace must be compiled with the OpenPegasus cimmofl compiler in a single call using the -m option on the cimmofl MOF compiler to generate the C++ source output that represents the classes/qualifiers to be compiled into the target namespace. Typically this means building a single mof file that represents the include of all of classes and qualifiers for the target namespace. The following is an example of such a mof file, the root_PG_Internal-namespace.mof file #pragma include("CIM2131/Core_Qualifiers.mof") #pragma include("Pegasus/Internal/VER20/PG_InternalSchema20.mof") The c++ source for that namespace is built with cimmofl using the -m option to generate the c++ source file defining the namespace and its contents.. Within a Makefile the repository compile this can be defined as: SCHEMAS=$(PEGASUS_ROOT)/Schemas CIMMOFL=cimmofl -d -W -m repository: @ $(CIMMOFL) root/PG_Internal -I $(SCHEMAS) \ root_PG_Internal_namespace.mof -m - Generate memory-resident repository source files for the class and qualifier definitions. -d - Discard Description qualifiers -W - Bypass the warning that you are using the cimmofl compiler This builds all of the classes and qualifiers for the root/PG_Internal namespace and outputs the result to the file root_PG_Internal_namespace.h and .cpp files for installation into the embedded system. The input mof is contained in root_PG_Internal_namespace.mof. It is the responsibility of the developer to encapsulate all of the mof required for this namespace into the single input file. NOTE: There is a working example of this build mechanism for VxWorks in the directory pegasus/vxworks/cimserver Building Repositories with Filterd Sets of Classes Normally an OpenPegasus system does not require the complete DMTF class hiearchy for any selected profile or set of providers. However, the task of manually reducing the full set of DMTF and user classes to the required subset is both error prone and tedious. Each leaf class implemented in a provider requires a set of additional classes in the repository that represent the class hiearchy for this target class and association and associated classes that may be used by this class. Therefore, the cimmofl compiler includes a mechanism that will aid in the filtering of classes to be compiled. The compiler accepts a supplementary file with a commandline option (NOTE: today the option is -c but that is temporary) that defines a supplementary file containing a list of classes. The compiler will filter the classes to be compiled from the input mof to those classes on this list and classes that are associated with these classes as: * superclasses in the assiearchy * Association and associated classes directly associated with the classes in this list. Thus, the user should be able to define the required classes for any namespace as the list of classes defined in the profiles to be incuded in the namespace. Note that there are some classes required by OpenPegasus and these classes must also be in this list. The Description Qualifiers in the Repository Typically, the Description Qualifiers take a significant percentage of the space for Class and Qualifier declaractions. It appears that with the memory resident repository, about 666666 the total space usage for the repository in memory is the Description Qualifiers. Therefore, to provide for an absolutely minimal class repository, an option has been added to the cimmofl compiler to discard the Description qualifiers and the MOF is compiled. This is option -d and the only effect is that any Description Qualifiers in the input MOF are discarded from the class and qualifier objects as they are compiled. Memory-Resident Repository Size The key resource parameter for the memory-resident class repository is the size. Typically, the size of the repository is about 5% to 10% of the corresponding disk repository. As an example, the compile of the complete 2.15 repository yields a repository that is used about 1.2 MB of memory with the Descripton qualifiers and about .5 MB without the Description Qualifiers The actual size of the class repository for each namespace can be determined by TBD. Persistence of the Memory-Resident Repository Instance Repository The instance repository is maintained completely in memory and it is the responsibility of the final implementor of the system to provide a set of functions that will provide persistence of the instances in this repository by implementing a set of callback functions for saving and restoring the repository. The functions required to be implemented to accomplish this are defined in PEP 307 and an example of these callback functions is provided in the sample embedded server define in the file pegasus/vxworks/cimserver/cimserver.cpp If the embedded system implementor does not chose to implement these functions, the instance repository is considered transient and is started empty upon each startup of the server.