<?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_d0e590125_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_d0e590136_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>