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