1 karl 1.1.2.2 Title: The OpenPegasus memory-resident repository
|
2 karl 1.1.2.1 Date: 1 November 2007
|
3 karl 1.1.2.2 Reference: PEP 307
4 Status: Draft
|
5 karl 1.1.2.1
|
6 karl 1.1.2.2 Overview of the Memory-Resident Repository
|
7 karl 1.1.2.1
|
8 karl 1.1.2.2 The memory-resident repository is an implementation of the
9 OpenPegasus CIM Class and Instance repository that operate
10 completely in memory and was designed to be used primarily by
11 embedded systems. It has the following characteristics.
|
12 karl 1.1.2.1
|
13 karl 1.1.2.2 1. The class repository is read-only and must be built and installed
14 as part of the server startup. There is no capability to add,
15 modify, delete classes or qualifiers once the OpenPegasus server
16 has been built.
|
17 karl 1.1.2.1
|
18 karl 1.1.2.2 2. The instance repository is maintained in core and is fully
19 read/write. The persistence of the instance repository is
20 maintained through a set of callbacks that the system creator must
21 create to save and restore the instance repository.
|
22 karl 1.1.2.1
|
23 karl 1.1.2.2 How to Build the Memory-Resident Class Repository
|
24 karl 1.1.2.1
|
25 karl 1.1.2.2 Thisepository is built with the Pegasus compiler cimmofl. Note that in
26 the memory-resident repository there is no capability to modify the class
27 repository subsequent to building the system so the complete class
28 repository must be compiled prior to building the system.
|
29 karl 1.1.2.1
|
30 karl 1.1.2.2 To build the memory-resident repository, first determine the CIM namespaces
31 to be used and the classes that will be included in each namespace.
|
32 karl 1.1.2.1
|
33 karl 1.1.2.2 The complete set of classes and qualifiers for a single namespace must be
34 compiled with the OpenPegasus cimmofl compiler in a single call using
35 the -m option on the cimmofl MOF compiler to generate the C++ source
36 output that represents the classes/qualifiers to be compiled into the
37 target namespace.
|
38 karl 1.1.2.1
|
39 karl 1.1.2.2 Typically this means building a single mof file that represents the
40 include of all of classes and qualifiers for the target namespace.
41 The following is an example of such a mof file, the
42 root_PG_Internal-namespace.mof file
|
43 karl 1.1.2.1
|
44 karl 1.1.2.2 #pragma include("CIM2131/Core_Qualifiers.mof")
45 #pragma include("Pegasus/Internal/VER20/PG_InternalSchema20.mof")
|
46 karl 1.1.2.1
|
47 karl 1.1.2.2 The c++ source for that namespace is built with cimmofl using the -m option
48 to generate the c++ source file defining the namespace and its
49 contents..
|
50 karl 1.1.2.1
|
51 karl 1.1.2.2 Within a Makefile the repository compile this can be defined as:
|
52 karl 1.1.2.1
|
53 karl 1.1.2.2 SCHEMAS=$(PEGASUS_ROOT)/Schemas
54 CIMMOFL=cimmofl -d -W -m
|
55 karl 1.1.2.1
|
56 karl 1.1.2.2 repository:
57 @ $(CIMMOFL) root/PG_Internal -I $(SCHEMAS) \
58 root_PG_Internal_namespace.mof
|
59 karl 1.1.2.1
|
60 karl 1.1.2.2 -m - Generate memory-resident repository source files for the class and
|
61 karl 1.1.2.1 qualifier definitions.
|
62 karl 1.1.2.2 -d - Discard Description qualifiers
|
63 karl 1.1.2.1 -W - Bypass the warning that you are using the cimmofl compiler
64
|
65 karl 1.1.2.2 This builds all of the classes and qualifiers for the root/PG_Internal
66 namespace and outputs the result to the file root_PG_Internal_namespace.h
67 and .cpp files for installation into the embedded system.
68
69 The input mof is contained in root_PG_Internal_namespace.mof. It is the
70 responsibility of the developer to encapsulate all of the mof required
71 for this namespace into the single input file.
|
72 karl 1.1.2.1
|
73 karl 1.1.2.2 NOTE: There is a working example of this build mechanism for VxWorks in
74 the directory
|
75 karl 1.1.2.1
76 pegasus/vxworks/cimserver
77
|
78 karl 1.1.2.2 Building Repositories with Filterd Sets of Classes
79
80 Normally an OpenPegasus system does not require the complete DMTF class
81 hiearchy for any selected profile or set of providers. However,
82 the task of manually reducing the full set of DMTF and user
83 classes to the required subset is both error prone and tedious.
84 Each leaf class implemented in a provider requires a set of
85 additional classes in the repository that represent the class
86 hiearchy for this target class and association and associated
87 classes that may be used by this class.
88
89 Therefore, the cimmofl compiler includes a mechanism that will aid
90 in the filtering of classes to be compiled. The compiler accepts
91 a supplementary file with a commandline option (NOTE: today the
92 option is -c but that is temporary) that defines a supplementary
93 file containing a list of classes. The compiler will filter the
94 classes to be compiled from the input mof to those classes on this
95 list and classes that are associated with these classes as:
96
97 * superclasses in the assiearchy
98 * Association and associated classes directly associated with the
99 karl 1.1.2.2 classes in this list.
100
101 Thus, the user should be able to define the required classes for
102 any namespace as the list of classes defined in the profiles to be
103 incuded in the namespace.
104
105 Note that there are some classes required by OpenPegasus and these
106 classes must also be in this list.
107
108 The Description Qualifiers in the Repository
109
110 Typically, the Description Qualifiers take a significant
111 percentage of the space for Class and Qualifier declaractions. It
112 appears that with the memory resident repository, about 666666 the
113 total space usage for the repository in memory is the Description
114 Qualifiers. Therefore, to provide for an absolutely minimal class
115 repository, an option has been added to the cimmofl compiler to
116 discard the Description qualifiers and the MOF is compiled.
117 This is option -d and the only effect is that any Description
118 Qualifiers in the input MOF are discarded from the class and
119 qualifier objects as they are compiled.
120 karl 1.1.2.2
121 Memory-Resident Repository Size
122
123 The key resource parameter for the memory-resident class
124 repository is the size. Typically, the size of the repository is
125 about 5% to 10% of the corresponding disk repository. As an
126 example, the compile of the complete 2.15 repository yields a
127 repository that is used about 1.2 MB of memory with the Descripton
128 qualifiers and about .5 MB without the Description Qualifiers
129
130 The actual size of the class repository for each namespace can be
131 determined by TBD.
132
133 Persistence of the Memory-Resident Repository Instance Repository
134
135 The instance repository is maintained completely in memory and it
136 is the responsibility of the final implementor of the system to
137 provide a set of functions that will provide persistence of the
138 instances in this repository by implementing a set of callback
139 functions for saving and restoring the repository. The functions
140 required to be implemented to accomplish this are defined in PEP
141 karl 1.1.2.2 307 and an example of these callback functions is provided in the
142 sample embedded server define in the file
143
144 pegasus/vxworks/cimserver/cimserver.cpp
145
146 If the embedded system implementor does not chose to implement
147 these functions, the instance repository is considered transient
148 and is started empty upon each startup of the server.
149
|
150 karl 1.1.2.1
151
152
|