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