pegasus/Attic/readme.EmbeddedSystemBuild - diff

Return to readme.EmbeddedSystemBuild CVS log

Up to [Pegasus] / pegasus / Attic

Diff for /pegasus/Attic/readme.EmbeddedSystemBuild between version 1.1 and 1.1.2.2

version 1.1, 2007/11/01 15:37:10

version 1.1.2.2, 2007/11/13 23:08:18

Line 0

Line 1

Title: Building Pegasus for Embedded Systems

Date: 1 November 2007

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

When building for embedded systems typically the server is built targeted

to one platform and the clients and support tools are build targeted to

another (host) platform. Thus, for example, for VxWorks, the cim server

would be targeted to the target VxWorks platform and the remiaining

components of Pegasus (clients, compiler, end-end tests) would be

targeted towards the development system.

The 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 in any case, two separate build sequences are required

for a complete Pegasus build, the target platform build (cross compile)

of the cimserver and server unit tests and the host build. The sections

below describe these processes.

Note that this work has expanded the make structure of pegasus to include

a new make configuration 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

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

1. Set up a configure.mak in the pegasus source root directory with the

specific directives for the target make. Note that there are several

sample configure.mak files defined in the pegasus.vxworks directory.

Since there may be a number of variations of the make structure

depending on the test configuraiton, it is logical to set up a

configure.mak for each and simply copy or softlink the correct one

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

The host platform build is the same as as any normal pegasus build.

It is initiated through the top level make file and builds all

components of the envrionment for execution on the host system.

Typically this can be executed with the alternatives defined below.

make new world -- builds everything

make -- build the source

make repository -- builds the repository for the host system.

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

configuration for the target build. It need not be used for the host

build. It can be used to generate parameters for this build

Special characteristics of the Embedded OpenPegasus Server

OpenPegasus implemented several special characteristics to support

embedded platforms including:

1. Memory-Resident Repository (PEP 307)

2. Static providers (PEP 309)

3. Single image build that produces a single output file containing

the server, providers, and the memory-resident class repository.

This section provides an overview of how to create a complete embedded

server.

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

See the note readme.MemoryResidentRepository file for detailed

information on the memory-resident repository

Building Providers

See the note readme.StaticProviders for detailed information on building

static providers for OpenPegasus embedded systems.

Legend:

Removed from v.1.1
changed lines
	Added in v.1.1.2.2

No CVS admin address has been configured