version 1.1.2.1, 2007/11/01 15:37:10
|
version 1.1.2.2, 2007/11/13 23:08:18
|
|
|
Date: 1 November 2007 | Date: 1 November 2007 |
Status: Draft | Status: Draft |
| |
|
Overview |
|
There are some signnificant differences between implementing |
|
Pegasus for an embedded system with limited resources and for a |
|
general purpose server or client platform. Typically the |
|
differences are: |
|
|
|
1. The whole build process is different in that the server is |
|
built on a host system for a different target system. |
|
|
|
2. The sofware resources such as shells, etc. are significantly |
|
limited in the target platform. |
|
|
|
3. Memory resources are often severly limited and with absolute |
|
limits without swap space, etc. |
|
|
|
4. The platform is often completely defined before installation |
|
with no capabilities for extension (new providers, etc.) and |
|
minimal capabilities for change of functionality and |
|
parameterization. |
|
|
|
Therefore, to enable improved use on these platforms Pegasus has |
|
been modified with a number of options that we hope will help |
|
embedded system implementors create more effective |
|
implementations. |
|
|
|
NOTE: Today this has been designed around the usage in the VxWorks |
|
platform but much of this functionality is considered general. |
|
|
|
The major area of effort include: |
|
|
|
1. Separate of the server and client builds |
|
|
|
2. Building the complete Pegasus application as a single image. |
|
a. Move from dynamic library build to static build |
|
b. Add concept of static providers (Providers linked with the |
|
server) |
|
c. Add concept of memory-resident repository. |
|
d. Limit the capability to modify parameters and provide for |
|
parameter setup as part of server start. (NOT DONE YET) |
|
e. Set limits on memory usage and control memory usage (NOT |
|
DONE YET) |
|
|
|
3. Removing server functionality not required for the embedded server. |
|
|
|
The following sections define several particular components of |
|
functionality and the build process particular to embedded |
|
systems. |
| |
Separation of the server and client builds | Separation of the server and client builds |
| |
When building for embedded systems typically the server is built targeted to one |
When building for embedded systems typically the server is built targeted |
platform and the clients and support tools are build targeted to another (host) |
to one platform and the clients and support tools are build targeted to |
platform. Thus, for example, for VxWorks, the cim server would be targeted to |
another (host) platform. Thus, for example, for VxWorks, the cim server |
the target VxWorks platform and the remiaining components of Pegasus (clients, |
would be targeted to the target VxWorks platform and the remiaining |
compiler, end-end tests) would be targeted towards the development system. |
components of Pegasus (clients, compiler, end-end tests) would be |
|
targeted towards the development system. |
Pegasus build environment has been extended to make this possible. The user may |
|
elect to work from either a single source tree or multiple source trees. But |
The Pegasus build environment has been extended to make this possible. |
in any case, two separate build sequences are required for a complete Pegasus |
The user may elect to work from either a single source tree or multiple |
build, the target platform build (cross compile) of the cimserver and server unit tests and the |
source trees. But in any case, two separate build sequences are required |
host build. The sections below describe these processes. |
for a complete Pegasus build, the target platform build (cross compile) |
|
of the cimserver and server unit tests and the host build. The sections |
Note that this work has expanded the make structure of pegasus to include a new make configuration |
below describe these processes. |
file (config.mak) located in the PEGASUS_ROOT directory. If this file exists, the definitions |
|
included in the file are included in the mak/configure.mak file which means that this file |
Note that this work has expanded the make structure of pegasus to include |
can be used to setup configuration parameters for the make. The host / target make structure |
a new make configuration file (config.mak) located in the PEGASUS_ROOT |
uses this new file. |
directory. If this file exists, the definitions included in the file are |
|
included in the mak/configure.mak file which means that this file |
|
can be used to setup configuration parameters for the make. The |
|
host and target make structure uses this new file. |
| |
| |
Building the server for the target platform | Building the server for the target platform |
| |
1. Set up a configure.mak in the pegasus source root directory with the specific |
1. Set up a configure.mak in the pegasus source root directory with the |
directives for the target make. Note that there are several sample configure.mak |
specific directives for the target make. Note that there are several |
files defined in the pegasus.vxworks directory. Since there may be a number of variations |
sample configure.mak files defined in the pegasus.vxworks directory. |
of the make structure depending on the test configuraiton, it is logical to set up a |
Since there may be a number of variations of the make structure |
configure.mak for each and simply copy or softlink the correct one into the pegasus source root. |
depending on the test configuraiton, it is logical to set up a |
|
configure.mak for each and simply copy or softlink the correct one |
2. |
into the pegasus source root. |
|
NOTE: There are several sample configure.mak files in the |
|
direcotry pegasus/vxworks/configuration each named for the |
|
appropriate vxworks target |
| |
|
2. Execute the Make to build the server image |
| |
| |
|
TBD: Note that this new procedure has not yet been tested |
| |
Building the clients on the host platform | Building the clients on the host platform |
| |
The host platform build is the same as as any normal pegasus build. It is |
The host platform build is the same as as any normal pegasus build. |
initiated through the top level make file and builds all components of the envrionment |
It is initiated through the top level make file and builds all |
for execution on the host system. Typically this can be executed with the alternatives |
components of the envrionment for execution on the host system. |
defined below. |
Typically this can be executed with the alternatives defined below. |
| |
make new world -- builds everything | make new world -- builds everything |
make -- build the source | make -- build the source |
|
|
| |
There is no specific make today to simply build the non-server components. | There is no specific make today to simply build the non-server components. |
| |
NOTE: The $PEGASUS_ROOT/configure.mak is normally used to set up the the configuration for |
NOTE: The $PEGASUS_ROOT/configure.mak is normally used to set up the |
the target build. It need not be used for the host build. It can be used to generate |
configuration for the target build. It need not be used for the host |
parameters for this build |
build. It can be used to generate parameters for this build |
| |
| |
Special characteristics of the Embedded OpenPegasus Server | Special characteristics of the Embedded OpenPegasus Server |
| |
OpenPegasus implemented several special characteristics to support embedded platforms |
OpenPegasus implemented several special characteristics to support |
including: |
embedded platforms including: |
| |
1. Memory-Resident Repository (PEP 305) |
1. Memory-Resident Repository (PEP 307) |
2. Static providers |
2. Static providers (PEP 309) |
3. Single image build that produces a single output file containing the server, |
3. Single image build that produces a single output file containing |
providers, and the memory-resident class repository. |
the server, providers, and the memory-resident class repository. |
|
|
This section provides an overview of how to create a complete embedded server. |
This section provides an overview of how to create a complete embedded |
Note that there is a working example in the directory vxWorks/cimserver of a |
server. |
build with some sample providers and a complete class repository containing 3 |
|
namespaces. |
Note that there is a working example in the directory vxWorks/cimserver of |
|
a build with some sample providers and a complete class repository |
|
containing 3 namespaces. |
| |
Building the Memory-Resident Repository | Building the Memory-Resident Repository |
| |
See the note readme.MemoryResidentRepository file for detailed information on the |
See the note readme.MemoryResidentRepository file for detailed |
memory-resident repository |
information on the memory-resident repository |
| |
Building Providers | Building Providers |
| |
See the note readme.StaticProviders for detailed information on building static |
See the note readme.StaticProviders for detailed information on building |
providers for OpenPegasus embedded systems. |
static providers for OpenPegasus embedded systems. |
| |
| |
| |