<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35" xml:lang="en"><title>Device
Variant Using Multiple Keyspace Files</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>This topic describes the use of multiple keyspace files on multiple ROFS
layers to create a device variant. </p>
<section><title>Introduction</title> <p>The central respository consists of
keyspaces used to store application settings. The device variant creators
need to modify these settings for every variant of the device. </p> <p>In
the older method the variant engineer has to branch out the exisiting keyspace
files , modify the settings and reflash the device with the new keyspace files.
The disadvantage of the older method is that the variant engineer has to maintain
multiple keyspace files. The modified keyspace must have the same files name
as the existing one. </p> </section>
<section><title>Multiple ROFS layers </title> <p>The central repository now
supports keyspace that is composed of multiple files. A new keyspace file
is created for a new ROFS layer. This enables the variant engineers to modify
a specific setting in the keyspace in one layer and merge the repository with
the new settings. The new feature to modify specific settings of a keyspace
reduces the time to create different variants. </p> </section>
<section><title>Merge the settings</title> <p>The figure below shows how a
specific setting is modified in the new meachnism. In the example below the
keyspace d is modified in the new ROFS layer to create a variant. The central
repository reads the keyspace files and merges the modified settings of <codeph>keyspace
d</codeph>. The settings in the higher ROFS layer get the priority of the
settings. The higher ROFS layers cannot modify the global properties of the
keyspaces like metadata, owner information and the access control information. </p> <fig id="GUID-BABA2027-0E54-575A-8A59-EB771CF46529">
<title>              Central repository - Modify a setting            </title>
<image href="GUID-D7179664-C442-5253-9925-994CA0C63B50_d0e577831_href.png" placement="inline"/>
</fig> <p>The figure below shows how a new setting is added to the central
repository keyspace. </p> <fig id="GUID-B1ED9F5D-4490-5F61-A084-44C8C6C0978C">
<title>              Central repository - Add a new setting            </title>
<image href="GUID-3A07445A-1CD4-5556-BE65-553A4A251789_d0e577842_href.png" placement="inline"/>
</fig> </section>
<section><title>Advantages</title> <p>The advantages of using
multiple ROFS layer to create device variant are: </p> <ul>
<li id="GUID-EED83088-C966-5206-94B3-4B9B693F6CF7"><p>variant engineers can
modify selective settings in a keyspace </p> </li>
<li id="GUID-5FCD32A3-8780-5B5C-BE29-0A6BAA068EF6"><p>no need to branch and
maintain multiple keyspace files for each variant created </p> </li>
<li id="GUID-89B96F5E-F33D-5512-889A-98D6A9A35033"><p>central repository can
detect the multiple keyspace files at run time and merge the settings as one
keyspace </p> </li>
</ul> </section>
<section><title>Guidelines</title> <p>The following are some guidelines to
use the multiple ROFS layers to create device variant: </p> <ul>
<li id="GUID-2D54FF98-37FE-554A-9C33-A9E60FFA6EF8"><p>Use the binary files
(CRE) or text files to initialise the keyspaces </p> </li>
<li id="GUID-97C5701A-58A5-57FD-A1F6-B36CB169D073"><p>Do not use the combination
of text and binary files for a keyspace. Use one format of the initialisation
files. </p> </li>
<li id="GUID-1A5774F2-9CD9-509C-B17C-83990C51973F"><p>The keyspace files in
higher ROFS layers must not modify the global properties such as metadata,
owner information and access control information. </p> </li>
</ul> </section>
<section><title>Errors</title> <p>The following table shows the possible errors
that may occur in use of multiple ROFS layers for device variant creation: </p> <table id="GUID-78196B5E-6474-5C23-9488-10290CA7D3D0">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<thead>
<row>
<entry>Error</entry>
<entry>Reason for the error</entry>
</row>
</thead>
<tbody>
<row>
<entry><p> <codeph>CENREPCLI: Panic 8</codeph>  </p> </entry>
<entry><p>The binary files (CRE) must be converted with the new central repository
conversion tool. </p> </entry>
</row>
<row>
<entry><p> <codeph>CENREPCLI: Panic 9</codeph>  </p> </entry>
<entry><p>The keyspace files in the higher layer is trying to modify a global
property </p> </entry>
</row>
<row>
<entry><p> <codeph>CENREPCLI: Panic 10</codeph>  </p> </entry>
<entry><p>Higher layer keyspace file is trying to modify a type of a setting
in the lower layer </p> </entry>
</row>
<row>
<entry><p> <codeph>CENREPCLI: Panic 11</codeph>  </p> </entry>
<entry><p>The default ROFS layer file is associated with <codeph>exattrib=u
                  </codeph> attribute </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
</conbody><related-links>
<link href="GUID-E3BE62B2-9625-5F79-84A4-0248A3F36225.dita"><linktext> Central
Repository Access Guide</linktext></link>
<link href="GUID-1C683226-C142-5C7B-BD20-060058352B08.dita"><linktext>Central Repository
Guide </linktext></link>
<link href="GUID-3D152CC5-AF20-520A-AB67-457F956A5551.dita"><linktext>Device Variant
With Multiple ROFS Layers                 Tutorial </linktext></link>
</related-links></concept>