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.