--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-EBF4F1F1-F76B-455B-B8EE-B7965CF0717E.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,49 @@
+<?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-EBF4F1F1-F76B-455B-B8EE-B7965CF0717E" xml:lang="en"><title>The LDD/PDD
+Model</title><shortdesc>This document describes how device drivers are implemented as logical
+device drivers (LDDs) and physical device drivers (PDDs).</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-4549DF88-EEB0-4CF2-BC93-A234E3ED553F">             <p>Device
+driver DLLs come in two types - the logical device driver (LDD), and the physical
+device driver (PDD). Typically, a single LDD supports functionality common
+to a class of hardware devices, whereas a PDD supports a specific member of
+that class. This means that the generic code in the LDD only needs to be written
+once, and the same user-side API can be used for all variants of a device. </p> <p>Many
+PDDs may be associated with a single LDD. For example, there is a single serial
+communications LDD (<filepath>ECOMM.LDD</filepath>) which is used with all
+UARTs. This LDD provides buffering and flow control functions that are required
+with all types of UART. On a particular hardware platform, this LDD will be
+accompanied by one or more PDDs, which support the different types of UART
+present. A single PDD can support more than one UART of the same type; separate
+PDDs are only required for UARTs with different programming interfaces. Typically,
+the PDD is kept as small as possible. </p> <p>Only LDDs communicate with user-side
+code; PDDs communicate only with the corresponding LDD, with the variant or
+kernel extensions, and with the hardware itself. Device drivers provide their
+interface for user side applications by implementing a class derived from
+the Kernel API <xref href="GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066.dita"><apiname>RBusLogicalChannel</apiname></xref>. The functions of the
+derived class form a thin layer over the functions defined in <codeph>RBusLogicalChannel</codeph> and
+are commonly implemented inline and published in a header file. However, if
+the API functions need to do more complex tasks, then they can be implemented
+in their own DLL. The kernel also provides a API <xref href="GUID-92BAC78E-8ACF-3952-8E77-CCF93ED3BDC9.dita"><apiname>RDevice</apiname></xref>,
+which enables user side code to get information about a device. </p> <p>The
+following diagram shows the general idea: </p><fig id="GUID-CB291406-75EC-572E-8A21-280A5F0A6B9E">
+<title>              Device driver LDD/PDD model            </title>
+<image href="GUID-6EB38F10-849D-5763-96A0-A0A108982D67_d0e63496_href.png" placement="inline"/>
+</fig><p>To make porting to particular hardware platforms easier, some drivers
+make a further logical split in their PDD code between a platform-independent
+layer (PIL), which contains code that is common to all the hardware platforms
+that the driver could be deployed on, and a platform-specific layer (PSL),
+which contains code such as the reading and writing of hardware-specific registers. </p> <p>Depending
+on the device or the type of device to access, this split between LDD and
+PDD may not be necessary; the device driver may simply consist of an LDD alone. </p> 
+   </section>
+</conbody></concept>
\ No newline at end of file