<?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-FCCF9634-0610-5199-A37A-CF2EC9B73261" xml:lang="en"><title>Adaptation Quick Start</title><shortdesc>Adaptation involves extending software on the device to
support a given hardware component. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-BC149020-EE8D-55ED-8254-75B70A4A1D3E"><title>Adaptation
environment</title> <p>The functionality of a particular hardware
technology is enabled when an interface to the standard for that technology
is defined. </p> <p>The hardware is enabled when the following exist: </p> <ul>
<li id="GUID-70F0057C-32FA-5AC5-922B-9FA853950490"><p>LDD – Logical
Device Driver </p> </li>
<li id="GUID-554F5C6F-F718-5FFA-8685-31D8322A513C"><p>PDD – Physical
Device Driver </p> </li>
</ul> </section>
<section id="GUID-8298F0E2-1811-5C08-8C08-F6A5754EA678"><title>Kernel
extensions</title> <p>Kernel extensions provide additional functionality
in the kernel and run with the same access rights and permissions
as the rest of the kernel. </p> <p>Adaptation device drivers (LDD/PDD)
require low-level access to the device and implementing them as a
kernel extension gives them this access. </p> <p><b>LDD</b> </p> <p>Each LDD has the following features: </p> <ul>
<li id="GUID-7549B5B5-7E7C-5F7C-9A2F-81EB8FB7F9E7"><p>the LDD is a
packaged DLL </p> </li>
<li id="GUID-5A57648F-9657-5261-8068-4D7F946F1C04"><p>provides user
side functionality </p> </li>
<li id="GUID-740E0B4E-A993-577E-ACF4-2EDC8E8DE834"><p>loaded into
the kernel </p> </li>
<li id="GUID-0991A098-C7DC-5335-8AF1-567BD9C0EEF8"><p>calls a function
that opens a <xref href="GUID-A3CC1D95-4681-3349-A67C-F113A614041D.dita"><apiname>DLogicalChannel</apiname></xref>  </p> </li>
<li id="GUID-5BA91833-A9DC-5C07-B3CB-769FD2B4758C"><p>opens an <xref href="GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066.dita"><apiname>RBusLogicalChannel</apiname></xref>  </p> </li>
<li id="GUID-0BB01A79-8D94-5BDB-BE4C-7B1A015950EE"><p>allows user
code to communicate with the hardware and send commands to control
the hardware </p> </li>
<li id="GUID-9A42F726-DBF3-5559-A2D9-867B293D7A44"><p>defines an abstract
class that must be implemented in the PDD </p> </li>
</ul> <p>Mandatory – there must be one LDD for each hardware component. </p> <p id="GUID-1097C454-8236-5291-88FB-92F979FB3B78"><b>PDD</b> </p> <p>PDDs have the following features: </p> <ul>
<li id="GUID-83481281-B6B0-50D2-A8B0-EDF6FDF7632B"><p>the PDD is a
packaged DLL </p> </li>
<li id="GUID-3B0AAFEC-786C-5003-B71A-B686C49034B4"><p>provides access
to hardware </p> </li>
<li id="GUID-E23527A0-4082-51E3-A3B1-200952C7B071"><p>loaded into
the kernel </p> </li>
<li id="GUID-9436F11E-6E53-5990-A2D5-625AFA815FD9"><p>calls a function
that opens a physical channel </p> </li>
<li id="GUID-285B2015-34B2-5BC5-8903-2BBE47E35CF3"><p>receives control
commands and other communications through its interface with the LDD </p> </li>
<li id="GUID-E3BA0A9E-4856-5831-86E3-6BC7702C7CC7"><p>may be an extension
to an existing device driver </p> </li>
</ul> <p>Mandatory – there must be one PDD for each hardware platform
for each hardware component. </p> </section>
<section id="GUID-A20284FD-D793-5650-94DF-D4DCB6BC0CC2"><title>Using
Kernel extensions</title> <p>A Kernel Extension is additional functionality
that runs as part of the kernel. </p> <p>For example, access to the
SD Card is provided through a kernel extension. </p> <p><b>Adaptation ready architecture</b> </p> <p>Adaptation ready architecture
means the following have been created: </p> <ul>
<li id="GUID-90B150BC-C18A-5578-AC86-54D4525D28E4"><p>The LDD </p> </li>
<li id="GUID-73DF2D9B-E53A-51C8-93C5-60AC883DDE18"><p>The abstract
class that must be implemented in the PDD </p> </li>
<li id="GUID-82E50357-5AB6-5975-9630-A9C7382F2FBB"><p>The interface
to the user code </p> </li>
<li id="GUID-CBA9DF88-CF53-519D-A792-3DBD3B548F25"><p>Any optional
kernel extension DLLs </p> </li>
<li id="GUID-D887C2E9-04FC-504F-A09A-5D9227AD4AEC"><p>Optional reference
implementation PDD </p> </li>
</ul> <p id="GUID-C10B0527-A1E1-54B0-A4B6-E4E991FD24B8"><b>Adaptation options</b> </p> <p>There are broadly two types of hardware adaptation: </p> <ul>
<li id="GUID-716ACF8A-278F-5FDA-A27A-2634EB6F24E5"><p>New hardware </p> </li>
<li id="GUID-6E1419FA-99EB-5183-A1E3-5F998995D96E"><p>Updated hardware </p> </li>
</ul> <p> <i>New hardware</i>  </p> <p>The entire adaptation architecture,
as described above, must be defined. This includes: </p> <ul>
<li id="GUID-12A35E7B-3F03-5D4D-83C9-EA61BAD0D193"><p>Defining an
abstract class that the PDD creators are required to implement, creating
an LDD and so on. </p> </li>
<li id="GUID-EA64CF53-61C4-531D-89C2-6B580A6E75C4"><p>The architecture
enables the new hardware. </p> </li>
<li id="GUID-0AA5340B-647E-535C-B183-D0E886017093"><p>The architecture
allows hardware manufacturers to create their own implementation (PDD). </p> </li>
</ul> <p>New hardware adaptation will be supported with a reference
implementation, which will go a long way towards guiding the device
developer’s efforts. </p> <p> <i>Updated hardware</i>  </p> <p>Updated
hardware which provides new or modified functionality requires a new
PDD to be created to either extend the functionality of the existing
PDD or to replace the existing PDD. </p> <p>In most cases the new
functionality of the hardware will be enabled by extending the architecture
with a new extension PDD or be writing a new PDD that incorporates
all the existing and new functionality. </p> <p>There are situations
where the entire adaptation architecture needs to be extended or redesigned,
such as when a hardware component is extended in a way that was not
expected. The Bluetooth baseband radio being extended to provide Bluetooth,
802.11, and FM radio from the same hardware component, for example,
will require a redesign of the adaptation architecture so the LDD
knows about 802.11 and FM as well as Bluetooth. Such a redesign should
ensure older Bluetooth PDDs will still work while extending the possible
PDDs that will work with the LDD to include Bluetooth, 802.11, FM
radio, and a combination of the above. </p> </section>
<section id="GUID-AC29A1E3-4FAF-41EC-A08A-CCCE8B28AB02"><title>Where
to go next</title> <p>Adaptation is described in more detail in these
documents:</p><ul>
<li><xref href="GUID-D5EE0A17-2246-4CB3-9CE5-538F1E01F8D4.dita">What is
Adaptation?</xref></li>
<li><xref href="GUID-95BD3650-08CB-407D-969E-DFDB39B2FEFC.dita">What is
a Platform Service?</xref></li>
<li><xref href="GUID-C9923DF3-8425-4EB4-8066-FB5A92A85F5B.dita">Adaptation
Process Guide</xref></li>
</ul> </section>
</conbody></concept>