Chapter 2 CMM : A Runtime Derivative

In This Chapter

This chapter provides an overview of the requirements necessary to create your CMM as a runtime derivative. It briefly discusses the classes from which you can derive to create your CMM, namely

• KcsIO

• KcsProfile

• KcsProfileFormat

• KcsXform

In addition, the chapter discusses the extendable class, KcsStatus class.

The chapter starts by identifying the requirements for creating a CMM. Then, it suggests reasons you might derive from (or extend) each of the aforementioned classes to customize your CMM. The chapter approaches runtime derivation prerequisites from the perspective of program coding as well as configuration requirements. The chapter concludes with a discussion of profile requirements, since the primary reason for writing a custom CMM is to create profiles that it can manipulate.

Subsequent chapters detail how to create class derivatives.

Development Environment Requirements

The KCMS packages are automatically placed in a protected directory when you load them with the pkgadd(3)command. Copy the packages to a writable directory for development use.

To compile programs, you must use version 4.2 of the Sun(TM) Visual Workshop(TM) C++ compiler, which is included with Sun Visual Workshop C++ 3.0.

Requirements For Creating a CMM

A CMM is defined as:

• Color management techniques

• Data structures

• Profiles

The following steps summarize the requirements for creating a CMM that is a runtime derivative:

1. Understand the KCMS framework, its general principles, and the SDK "C" interface.

   This manual assumes your understanding of the KCMS framework "C" API functions described in the SDK manual KCMS Application Developer's Guide. Chapter 3, KCMS Framework Operations ," in this manual, shows you how the KCMS classes implement the framework.

2. Determine your color management requirements and whether you need to derive from or extend any of the KCMS framework classes to meet those requirements.

   This chapter suggests ways you can use each of the derivable KCMS classes to meet the special requirements of your CMM. See "Why You Might Derive From or Extend a KCMS Class " ," for details.

3. Understand the ICC profile format.

   If you want to use the ICC format with different color manipulations, you should familiarize yourself with the ICC profile format. For further discussion, see "Profiles" .

4. Understand the runtime mechanism for derivatives.

   See "Deriving Classes at Runtime " .

5. Understand the CMM naming conventions and the OWconfig file.

   See "Configuration Requirements" .

6. Implement your KCMS framework runtime extensions.

   This manual as well as the KCMS CMM Reference Manual describe the foundation library interfaces. You may also find it helpful to refer to the SDK manual KCMS Application Developer's Guide for information on the KCMS framework API.

7. Test your CMM.

   In addition to testing your CMM, you can verify that it adheres to the KCMS framework. See the DDK manual KCMS Test Suite User's Guide for details on an optional facility to do this.

8. Follow registration requirements for your CMM.

   If your profiles are ICC compliant and you intend to make them and/or your CMM available to the public, you must register your CMM Id with the ICC. If your CMM creates attributes for public use, these also must be registered (you don't need to register private attributes). And finally, if you derive from the KcsXform class (see "KcsIO Example" ), you must register transform Ids. For details on CMM registration requirements and who to contact, see the ICC profile format specification. The specification to which this version of KCMS conforms is a PostScript file located on-line in /usr/openwin/demo/kcms/docs/icc.ps. Check the web site at http://www.color.org for the most up-to-date version of the specification.

Why You Might Derive From or Extend a KCMS Class

The following sections give helpful information on why you might derive from or extend a particular KCMS class.

KcsIO

If you have special I/O considerations, you might want to create a KcsIO class derivative. It is a simple I/O protocol that most devices support. For example, this version of KCMS includes an X11 Window System derivative (kcsSUNWIOxwin.so.1) and a Solaris file derivative (kcsSUNWIOsolf.so.1). The code for the latter is included in the /opt/SUNWddk/kcms/src directory.

The framework supports file-, memory-, and network-based derivatives. Objects use a static store to read from or write to data; a common type of static store is a file on disk. A static store is a hardware- or platform-independent mechanism for generation and regeneration. Generation is the first time data is read from a static store and an object is instantiated from that data; the data is constructed from the saved state. Regeneration, or loading occurs when a derivative brings back all of its state and functionality, after it has been minimized, from its static store. With minimization and regeneration the object is already instantiated. A minimized object contains sufficient information to generate itself from a static store [typically just its unique identifier(UID)].

See Chapter 4, KcsIO Derivative ," for information on creating a KcsIO class derivative.

KcsProfile

Derive a new KcsProfile class for characterization and calibration, additional functionality, or new transformation derivatives. Usually, this involves overriding one of the update methods to actually produce a new KcsXform derivative. Once the transformation is saved to the static store, the runtime load mechanism automatically handles it from then on, as long as the CMM is installed on the loading system. Since you can supply profiles directly that contain new KcsXform derivatives, the only derivative necessary to supply is the one derived from the KcsXform class. However, if the profile used to contain these new KcsXform derivatives is the KcsProfile derivative, it overwrites the new KcsXform type with one of its own when calibrated.

See Chapter 5, KcsProfile Derivative ," for information on creating a KcsProfile class derivative.

KcsProfileFormat

You can create a KcsProfileFormat class derivative to support an existing non-ICC profile format, a new profile format, or possibly a set of data that is not an ICC profile (for example, a tag encoded TIFF file). To build a KcsAttributeSet instance within a KcsProfileFormat instance and a set of KcsXform derivatives, enough information in a properly tagged TIFF image might exist.

The CMM Id and version must be in a known location in the profile header. This is always the case with the ICC profile format. See "ICC Profile Header " ," for details. Other profile formats must be formatted to conform to this requirement so that the KCMS framework can form the keys to locate the format's runtime loadable module.

See Chapter 6, KcsProfileFormat Derivative ," for information on creating a KcsProfileFormat class derivative.

KcsXform

Typically you create a KcsXform class derivative when you create a CMM. The KcsXform is the most common derivative, since most color management suppliers have their own type of transformation technology. Most color technology involves manipulating matrixes and transforms. This class allows you to define a transform and its methods.

See Chapter 7, KcsXform Derivative ," for information on creating a KcsXform class derivative.

KcsStatus

The KcsStatus class represents a consistent object-oriented way of returning results from all the KCMS methods. It enables each of the following to be represented:

• Error and warning values

• Error text descriptions

• Error conversions to and from a KcsStatusId

• Error comparisons

• External mappings through the KCMS C API

• Message extraction for language localization

You do not actually derive from the KcsStatus class: you extend it. You override an error and warning message function to provide your own error and warning messages. It is recommended that you override KcsStatus functions with message extraction for language localization. You are not required to provide your own messages. The KCMS-framework error and warning messages may be sufficient.

See Chapter 8, KcsStatus Extension ," for information on extending the KcsStatus class.

Deriving Classes at Runtime

The KCMS framework uses a model that allows derivation of classes at runtime. This model changes and augments the default functionality in the pre-compiled shared library. The KCMS framework uses the Solaris runtime-loader interface. See the dlopen(3X) and dlsym(3X) man pages for more information. The runtime derivation model uses C-based routines to load, unload, initialize, terminate, and allocate at runtime.

To enable runtime derivation, you must code your CMM according to special requirements and configure each derived class it contains. Each of these topics is addressed in the sections below. See "Runtime Derivation Coding Requirements " and "Configuration Requirements" .

Runtime Derivation Coding Requirements

This section describes what you need to do in the code of each of your CMM derivatives so that the derivative can be executed at runtime.

Runtime Derivation Code Examples

For code examples showing how to use the wrapper functions and entry points described in the sections below, see the chapter describing that derived class. The chapters are:

• Chapter 4, KcsIO Derivative "

• Chapter 5, KcsProfile Derivative "

• Chapter 6, KcsProfileFormat Derivative "

• Chapter 7, KcsXform Derivative "

In addition, see the sample programs in /opt/SUNWddk/kcms/src. The directory contains brief sample programs that illustrate all the coding requirements described in this section.

Wrapper Functions

To allocate an object at runtime, you use wrapper functions. Wrapper functions are implemented in C and perform a C++-to-C conversion. The allocation routines return a pointer to the base class object that indicates to the C++ compiler what is returned, but not the definitions. As in typical C, you can reference symbols in a sharable library because the functions are defined as extern C {}().

These functions are written in C++ and call new()() (or its equivalent alternative). Since the shareable object code has all of the header information from the base class, the derivative is constructed properly and has the same structure as statically-linked code.

External Entry Points

You need to provide the KCMS framework with an external entry point to load each of your derivatives as an executable. The symbols are loaded and the derivative is called by the framework to access your derivative's functionality.

The types of entry points for a runtime derivative are:

• mandatory

• optional

• base-class specific

In the paragraphs that follow, XXXX refers to the base class identifier from which it is being derived. XXXX can only have the following values:

• IO

• Prof

• Pfm

• Xfrm

• Stat

Mandatory

For each runtime derivative, you must supply a C-based variable and an external entry point. Respectively, these are:

• KcsDLOpen()XXXXCount()()

• KcsCreate()XXXX()()

The KcsDLOpenStatusCount()()variable is the only requirement for extending the KcsStatus class.

KcsDLOpen()XXXXCount()()

extern

long

KcsDLOpen()XXXXCount();

KcsDLOpen()XXXXCount()()is the number of times the shareable object was opened. It is equivalent to the number of times the shareable object is being shared. The CMM should not set this variable. It is controlled by the KCMS framework.

KcsCreate()XXXX()()

KcsXXXX

*KcsCreateXXXX(KcsStatus *,

XXXX creation

args);

KcsCreate()XXXX()() is one of possibly many creation entry points. This entry point maps directly to the static create()XXXX()() methods of the base class from which it is being derived. The arguments following KcsStatus * are specific to the base class and are described in the appropriate class chapter. See the chapters describing the KcsIO, KcsProfile, KcsProfileFormat, and KcsXform classes (Chapter 4, KcsIO Derivative through Chapter 7, KcsXform Derivative , respectively). The CMM must support all declared create()XXXX()() methods; otherwise, applications receive CMM errors from calls to load()().

Optional

Runtime derivatives can supply the following external entry points:

• KcsInit()XXXX()()

• KcsCleanup()XXXX()()

It is highly recommended that you use the KcsInit()XXXX()() entry point to verify the version of the versions so that your CMM can use the profile data properly.

KcsInit()XXXX()()

KcsStatus

KcsInit()XXXX(long libMajor,

long libMinor,  		long *myMajor, long

*myMinor);

If you supply the KcsInit()XXXX()()entry point, the KCMS framework calls it when the shareable object is loaded for the first time. This initializes and derives private allocations before any creation method is called. KcsInit()XXXX()() checks for minor version numbering. See "Configuration Requirements" for more information.

KcsCleanup()XXXX()()

KcsStatus

KcsCleanup()XXXX()();

If you supply the KcsCleanup()XXXX()()entry point, the KCMS framework calls it when the shareable object is unloaded for the last time (when KcsDLOpen()XXXXCount = 0()). This cleans up shareable objects when they are no longer needed.

Base-Class Specific

Each base class also provides additional necessary and optional entry points. See the chapters describing the KcsIO, KcsProfile, KcsProfileFormat, and KcsXform classes (Chapter 4, KcsIO Derivative through Chapter 7, KcsXform Derivative , respectively), for detailed explanations.

Instantiation

You instantiate KCMS framework objects or any runtime derivations of that object with the following methods:

• createXXXX()()

• attach()()

• new()()

create()XXXX()()

You allocate an object with the create()XXXX()() method. This method combines sharing of the object with runtime derivative support. With chunk set-based objects, this function searches for a match through allocated objects. If it finds a match, it attaches to that object and returns its address. If it does not find a match or the object is not chunk set based, it searches for a match through objects in the runtime-loadable object files.

To maximize the runtime nature of the KCMS framework, it is recommended that you use the create()XXXX()() method whenever possible within your CMM derivative. It enables derivatives statically linked into an application or included directly in the KCMS framework's shared object libraries (such as, libkcs) to use the correct and latest version of your CMM derivative.

Note that the KcsStatus class extension is an exception to this recommendation. It passes back a status string rather than a pointer to a derivative, and only two C functions are written.

attach()()

You use the attach()() method to share an object. If an object already exists, it can be shared in memory with this method. You can share the object with other users of that object. Any changes in the object are applied to objects that share it. If you share an object, make sure that object does not change while your derivative is attached to it.

new()()

To get a new object of a specified type or a KCMS framework derivative, you use the new()() method. This allows a runtime derivative to actually override a built-in type after it has been released.

Initialization and Cleanup

The KcsLoadable class loads a runtime derivative's binaries when a create()() method is used. It generates the shared object's configuration file keywords based on class, derivative, and version identifiers. It retrieves the module name and loads the library. See "Creating OWconfig File Entries" for further information.

The KcsLoadable class then locates the KcsDLOpen()XXXXCount() variable. If KcsDLOpen()XXXXCount = 0, it locates and loads the KcsInit()XXXX()() entry point and, if available, calls it. Then the KcsCreate()XXXX()() entry point is located and loaded. If everything is successful, the KcsCreate()XXXX()()entry point is called.

When the last of a specific derivative type is deallocated and the KcsCleanup()XXXX()() entry point is available, it is located, loaded, and called.

Configuration Requirements

This section tells you what you need to know to load your CMM. It explains how to name derived classes and how to update the OWconfig file for each derived class in your CMM.

CMM Filename Convention

A module (or CMM) name should follow this convention:

kcs<STOCK

SYMBOL><CLASS><unique

identifier>.so.<version>

Table 2-1 describes each field in the CMM filename.

The version number in the #define and the version number in the module name must match. See icc.h for an example.

Table 2-2 lists a few KCMS CMM filenames.

CMM Makefile

You must install your CMM in /usr/openwin/etc/devhandlers. To copy the file into this directory, you must be superuser and you must set the file permissions to 755 so that it is executable.

See the sample makefile in /opt/SUNWddk/kcms/src for an illustration of how CMMs are compiled and installed, and how the CMM library names are associated with the CMM modules.

Creating OWconfig File Entries

You must include OWconfig library in the CMM linking. To link in this library, enter -lowconfig on the link command line . The OWconfig library is bundled with Solaris in /usr/openwin/lib/libowconfig.so. It provides routines to access the OWconfig file, which gets the name of the CMM class derivitive you want to dynamically load.

To advertise its existence of your CMM class derivative to the KCMS framework, you must add the name of the derivitive to the OWconfig file.

A generic OWconfig entry looks like this:

class="KCS_IO"

name="solf"

	kcsLoadableModule="kcsSUNWIOsolf.so.1";

Table 2-3 describes each field.

The above is just an example of the OWconfig file structure. You need to add an OWconfig file entry for each class you derive from or extend in your CMM. Examples of these entries are shown in the following paragraphs.

KcsIO Example

If you derive from the KcsIO class, you need to provide a KcsIO class entry such as the example entries below:

#KcsIO

class, Solaris profiles class="KCS_IO" name="solf"

	kcsLoadableModule="KcsSUNWIOsolf.so.1";  #KcsIO class, X11 window

system profiles class="KCS_IO" name="xwin"

	kcsLoadableModule="kcsSUNWIOxwin.so.1";

Note the name strings in the above examples. The KcsProfileType enumeration in kcstypes.h contains a type field that is a 4-character array described in hexadecimal form as a long, for example:

typedef

enum { 	KcsFileProfile					= 0x46696C65, /*File*/ 	KcsMemoryProfile					=

0x4D426C00, /*MBl*/ #ifdef KCS_ON_SOLARIS 	KcsWindowProfile					= 0x7877696E,

/*xwin*/ 	KcsSolarisProfile					= 0x736F6C66, /*solf*/ #else

	KcsWindowProfile					= 0x57696E64, /*Wind*/ #endif /* KCS_ON_SOLARIS */

	KcsProfileTypeEnd					= 0x7FFFFFFF, 	KcsProfileTypeMax					= KcsForceAlign

}KcsProfileType;

The OWconfig library turns the type field back into a string corresponding to the name field entry and searches all of the appropriate OWconfig class entries for that string.

KcsProfile Example

If you derive from the KcsProfile class, you need to provide a KcsProfile class entry such as the example entries below:

#KcsProfile

Class, Solaris default is KCMS #Default profile class, CMM Id == Profile

Format class="KCS_Prof" name="dflt"

	kcsLoadableModule="kcsEkProfkcms.so.1";  #KCMS profile, CMM Id ==

Profile Format class="KCS_Prof" name="KCMS"

	kcsLoadableModule="kcsEKProfkcms.so.1";

The key to loading a new version is the CMM Id (also called CMM Type), which is contained in bytes 4 through 7 in the ICC profile header). (See "ICC Profile Header " for details.) If there is not a match, the default entry dflt is used. You must load the proper CMM Id into the new profile's CMM Id attribute field for recognition of the module.

The default loadable KcsProfile module is the Solaris-supplied default.

The KcsProfile class is the base class that can contain transformations (KcsXform class) and a profile format (KcsProfileFormat class). Since the Kodak KcsProfile class is built into the library, you can use this mechanism to extend the calibration and characterization interface.

KcsProfileFormat Example

If you derive from the KcsProfileFormat class, you need to provide a KcsProfileFormat class entry such as the example entries below:

#Profile

format class, default is ICC #Default profile format, ICC, default CMM

class="KCS_Pfmt" name="acspdflt"

	kcsLoadableModule="kcsEKPfmticc30.so.1";  #ICC profile format,

KCMS CMM class="KCS_Pfmt" name="acspKCMS"

	kcsLoadableModule="kcsEKPfmticc30.so.1";

The profile format is determined from the profile file signature (also known as the magic number), which is contained in bytes 36-39 in the ICC profile header), and CMM Id (bytes 4-7 in the header). (See "ICC Profile Header " .) A check is performed to ensure that an ICC profile uses the magic number of the file. If another format is used, the magic number is used to load the module.

All profiles that are ICC profile format files should have a magic number equal to acsp, and they must have the ICC header included. The CMM Id is used to match the profile format with the correct derivative. If no match is found, the default entry (dflt) is used; therefore, you can use the supplied default profile format class for ICC profiles.

The name field syntax is: <Profile magic number><CMM Id>

The OWconfig file entry must match the resulting name. This also gives color management vendors the opportunity to support pre-ICC format profiles, provided they include the ICC header.

KcsXform Example

If you derive from the KcsXForm class, you need to provide a KcsXForm class entry such as the example entries below:

#ICC

interpolation table 8 bit, default CMM class="KCS_Xfrm"

name="mft1dflt"

	kcsLoadableModule="kcsEKXfrmucp.so.1";  #ICC interpolation table

16 bit, default CMM class="KCS_Xfrm" name="mft2dflt"

	kcsLoadableModule="kcsEKXfrmucp.so.1";  #ICC interpolation table

8 bit, default CMM class="KCS_Xfrm" name="mft1KCMS"

	kcsLoadableModule="kcsEKXfrmucp.so.1";  #ICC interpolation table

16 bit, default CMM class="KCS_Xfrm" name="mft2KCMS"

	kcsLoadableModule="kcsEKXfrmucp.so.1";  #KCMS universal color

processor table class="KCS_Xfrm" name="ucpKCMS"

	kcsLoadableModule="kcsEKXfrmucp.so.1";

The name field is a combination of a unique 4-character transform identifier and the CMM Id. (The transform identifier must be registered with the ICC if the profile and CMM are to be made available to the public.) The library turns name back into a string and searches all of the appropriate OWconfig class entries.

Inside an ICC profile, the type of transform is defined by a type identifier that indicates whether it is an 8- or 16-multi function table, indicated by the signature element of either the Lut8Type (mft1) or Lut16Type (mft2). Default values have been supplied for these cases: mft1dflt and mft2dflt.

KcsStatus Example

If you extend the KcsStatus class, you need to provide a KcsStatus class entry such as the example below:

#Extending

error messages class="KCS_STAT" name-"solm"

	kcsLoadableModule="kcsSUNWSTATsolm.so.1";

The name field is a 4-character string that uniquely identifies your set of error and warning messages.

To add your own error messages, supply a single "C" routine that translates your error value into an error string. Also supply a messages.po file for localization purposes. See Chapter 8, KcsStatus Extension " for detailed information.

If an OwnerId variable is set with the status message, the KcsStatus class dynamically loads the matching OwnerId that was set by the dynamically loaded class. The OwnerID is described in Chapter 8, KcsStatus Extension .

Updating the OWconfig File

Using the interactive program called OWconfig_sample, which is provided with the DDK, you can insert and remove configuration entries (class, name, and kcsLoadableModule) in the OWconfig file.

To update OWconfig file entries, you must be root. If you are not root or the /etc/openwin/server/etc path does not exist, the following error is generated:

OWconfile

file not created/updated. Check that you are root and /etc/openwin/server/etc

exists.

Start the OWconfig_sample program as follows:

example%

su example# ./OWconfig_sample

Inserting Entries

The following is an example of how to insert a configuration entry into the OWconfig file. Sample user responses are enclosed in brackets ([]).

Example 2-1 Inserting an OWconfig File Entry

ATTENTION:You must be

root to update the OWconfig file. Are you inserting an OWconfig entry? y/n 

[y]  You will be asked to supply a class, a name and a kcsLoadableModule to

create an entry such as the following: class = "SUN_Xfrm" name =

"acspdndp" kcsLoadable Module = "sunSUNWxfrmdndp.so.1"

Please see the KCMS CMM Developer's Guide for information  Enter the

profile class name in the form of XXX_IO, XXX_Prof, XXX_Prfmt, XXX_Xfrm, or

XXX_Stat. XXX is your unique cmm identifier, which must match the class name

of your derived class.  [KCS_Prof]  Enter the name of your cmm - it must match

the name in your derived class.  [dndp]  Enter the name of your dynamically

loadable module.  [kcsSUNWProfdndp.so.1]  This is your OWconfig entry. OK? y/n

 class = KCS_Prof name = dndp kcsLoadableModule = kcsSunWProfdndp.so.1  [y] 

Do you have more entries to create? y/n  [n]

The OWconfig_sample program above appends the entry to the OWconfig file.

Try inserting the entry shown in the above example:

1. Run the OWconfig_sample program. Be sure you are root.

   See "Updating the OWconfig File " .

2. Insert the user responses shown in Example 2-1 .

3. Check for the entry at the end of the OWconfig file.

   The new configuration entry is appended to the end of the /usr/openwin/server/etc/OWconfig file. For local machine use only, the /etc/openwin/server/etc/OWconfig file is updated.

Removing Entries

The following is an example of how to remove a configuration entry from the OWconfig file. Sample user responses are enclosed in brackets ([]).

Example 2-2 Removing An OWconfig File Entry

ATTENTION:You must be

root to update the OWconfig file. Are you inserting an OWconfig entry? y/n 

[n]  To remove an OWconfig entry:  Enter the unique class name for your module

for removal from the OWconfig file. The class name would be in the form

XXX_IO, XXX_Prof, XXX_Pfrmt, or XXX_Stat  [KCS_Prof]  Enter the unique cmm

name for your module for removal from the OWconfig file.  [dndp]  This is the

OWconfig entry to remove. OK? y/n  class = KCS_Prof name = dndp  [y]  Do you

have more entries to remove? y/n  [n]

The OWconfig_sample program removes the last entry in the OWconfig file.

Try removing the entry you inserted following Example 2-1 :

1. Run the OWconfig_sample program again. Be sure you are root.

   See "Updating the OWconfig File " .

2. Fill in the user responses shown in Example 2-2 .

3. Check the OWconfig file.

   The entry should no longer appear at the end of the file.

Version Numbering

Once OWconfigGetAttribute()() returns the module name, the version number is parsed out of the module name and compared to the global library version number located in kcsos.h to determine if this version can be executed.

The major version number in the module name must match the global variable located in the header file kcsrpc.h for an example.

Profiles

This chapter would not be complete without a discussion on profiles. You write a CMM to create profile(s) that meet your special requirements. This section describes the KCMS profile standard. It makes recommendations regarding the portability of the profiles your CMM creates. Finally, it explains how to set up the profiles so that your CMM can use them.

KCMS uses the ICC profile format as the default profile format. The ICC profile format specification to which this version of KCMS conforms is located on-line in /usr/openwin/demo/kcms/docs/icc.ps. (For the most current version of the ICC specification, check the web site at http://www.color.org.) By supporting the ICC specification, the profiles your CMM creates can be used on all participating vendors' color management systems.

Much of the work in processing and handling ICC format profiles is included by default in the framework. To speed your development cycle, use as much of this default technology as possible. You can develop your own profile format within the framework.

It is strongly recommended that you extend the ICC profile format rather than develop your own. If you do not use the ICC profile format your profiles will not be easily ported to other platforms.

ICC Profile Header

Table 2-4 shows the ICC profile header. For details on the profile header fields, see the ICC profile format specification. The KCMS-specific header is defined in icc.h, and KCMS attributes are registered with the ICC. (The profile header and all attribute structures and definitions that pertain to KCMS also are described in Chapter 5, "Profile Attributes," in the SDK manual KCMS Application Developer's Guide.)

Note that the CMM Id must in a fixed place (bytes 4-7) in the header .

Naming and Installing Profiles

Any profile you want to include in the KCMS library must be named according to specified conventions to avoid name clashes and promote portability. The paragraphs below explain how to name and install your profile so that it can be automatically used in the KCMS framework.

Naming Profiles

The KCMS profile name is a filename with the following naming convention:

<CMM

ID><stock

symbol><device>.<type>

Table 2-5 describes the fields in the profile filename:

Profile Filename Suffixes

Table 2-6 describes the various filename suffixes for profiles for the Solaris environment.

Installing Profiles

If you use the file type KcsSolarisFile in the KcsLoadProfile()() function, you must install profiles where the KCMS framework can locate them . The KCMS framework searches for profiles in the following directories in the order listed below:

1. Local current directory

   Typically a CMM creates profiles in the directory in which it is being run.

2. Directories specified by the KCMS_PROFILES environment variable

   KCMS_PROFILES is a colon-separated list of directory paths to profiles. You can set this variable on a per-user or work-group basis. You may want to use this variable to set the path to temporary profiles your CMM creates.

3. /etc/openwin/devdata/profiles

   This directory contains the local or machine-specific copies of configured profiles, for example, X Window System visual profiles.

4. /usr/openwin/etc/devdata/profiles

   This directory always contains read-only files.

All profiles for distribution (whether you create them or they are supplied with the Solaris operating system) should be written as superuser and read only to protect them from being overwritten.

If you use the file type KcsFile in the KcsLoadProfile()() function, when the application opens the profile, you can name it anything you want.

Supported Devices

For a list of the devices supported by the KCMS framework, see Appendix A, Supported Devices .