<?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-22CCA5B5-D4AB-4ABC-94C6-CD85EC470238" xml:lang="en"><title>System

Information</title><shortdesc>This topic describes various system information related to the

device drivers.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-8968BABB-32E5-4998-8E69-C8389D1E6B63">       <title>Presence

of PDD</title>       <p>Some drivers may only require an LDD, and not provide

a PDD. However, if the driver has a PDD, then the driver must inform the framework

of this. The LDD should set the <xref href="GUID-7616AA05-83E6-3989-AB9D-11AE01245BEB.dita#GUID-7616AA05-83E6-3989-AB9D-11AE01245BEB/GUID-EB891156-94D9-323A-AB23-7B5994CD95E3"><apiname>DLogicalDevice::iParseMask</apiname></xref> bitmask

with the <xref href="GUID-DD3574F6-5EA7-3E2E-B906-E1E320DE10CD.dita"><apiname>KDeviceAllowPhysicalDevice</apiname></xref> flag. If this flag

is not set, then the Kernel assumes that the driver does not have a PDD. </p> <codeblock id="GUID-F4A44E78-EA90-5D75-BC1F-48EF684F7F58" xml:space="preserve">// Logical Channel Second stage constructor

DExDriverLogicalDevice:: DExDriverLogicalDevice ()

    {

    iParseMask = KDeviceAllowPhysicalDevice | KDeviceAllowUnit;

    ...

    }</codeblock>     </section>

<section id="GUID-EFC4AE5D-6506-4B1F-A4E4-DBA31B456593"/>

<section id="GUID-E983D7DF-52C4-46FC-B633-BF08519D949D"><title>Capabilities</title> <p>The

device driver framework provides a method to set and provide general information

to the user on the capabilities of the device driver. Typically, implementations

simply return the version number of the LDD. The device driver framework allows

both the LDD and PDD to set the device capabilities. </p> <p>The user typically

calls the <xref href="GUID-92BAC78E-8ACF-3952-8E77-CCF93ED3BDC9.dita#GUID-92BAC78E-8ACF-3952-8E77-CCF93ED3BDC9/GUID-9C38652A-0135-360D-A54F-A9542C45E608"><apiname>RDevice::GetCaps()</apiname></xref> function to retrieve the device

capabilities. </p> <codeblock id="GUID-6801C06D-EEA1-505B-968A-8EF354961183" xml:space="preserve">RDevice device;

r = device.Open(KDriverName);

if (r==KErrNone)

    {

    TPckgBuf<RExDriver::TUartCaps> caps;

    device.GetCaps(caps);         

    ...

    device.Close();

    }</codeblock> <p> <i>Note:</i> The device capabilities in this context

refer to the services that the driver can offer. Do not confuse this with

the idea of platform security capabilities, which are completely different. </p></section>

<section id="GUID-73AD1B0E-2A31-4D44-A19C-E64A78281C27"><title> HAL handlers</title> <p>Symbian

platform provides a Hardware Abstraction Layer (HAL) interface that can be

used by device drivers and kernel extensions to provide information on device

specific attributes to user code. It comprises set and get interfaces used

by the Kernel and by user code. The attributes are divided into groups of

similar functionality, each of which is managed by a function called a HAL

handler. </p> <p>Drivers must register any HAL handlers they provide, and

de-register them when unloading. Kernel extensions do not remove their HAL

handlers. </p> <codeblock id="GUID-EE9D2192-92F1-5C9D-9E9C-4CFD5D2C6304" xml:space="preserve">// Adds a HAL entry handling function for the specified group of 

// HAL entries.

Kern::AddHalEntry(EHalGroupDisplay, &handler, this, 1);

// Removes the HAL handler

TInt Kern::RemoveHalEntry(EHalGroupDisplay);</codeblock> <p>The arguments

to <codeph>AddHalEntry()</codeph> are the ID of a HAL group, a pointer to

the handler function and a pointer to a data structure that will be passed

to the handler function. The HAL handler function prototype is defined by <xref href="GUID-A65A16CA-488D-3A16-A034-F01C9C0B9D15.dita"><apiname>THalFunc</apiname></xref>. </p> <codeblock id="GUID-B3B4A844-FA9B-54CC-A02C-90BB2388AFC8" xml:space="preserve">// Implementation of the kernel extension's exported function

EXPORT_C void TExClientInterface::MyExAPI()

    {

    …

    ExController->MyExAPI();

    …

    }

LOCAL_C TInt halFunction(TAny* aPtr, TInt aFunction, TAny* a1, 

        TAny* a2)

    {

    DLcdPowerHandler* pH=(DLcdPowerHandler*)aPtr;

    return pH->HalFunction(aFunction,a1,a2);

    }

TInt DLcdPowerHandler::HalFunction(TInt aFunction, TAny* a1, 

TAny* a2)

    {

    ...

    switch(aFunction)

        {

        ...

        }

    }</codeblock> <p>When the user calls <xref href="GUID-BD00E7FC-C234-3111-87A5-10F79EB0F2B8.dita#GUID-BD00E7FC-C234-3111-87A5-10F79EB0F2B8/GUID-9454F1B2-D525-3D6D-A872-C6457CACD4FC"><apiname>HAL::Set()</apiname></xref> or <xref href="GUID-BD00E7FC-C234-3111-87A5-10F79EB0F2B8.dita#GUID-BD00E7FC-C234-3111-87A5-10F79EB0F2B8/GUID-573C49D6-7763-37AE-B2B2-4C8FB1327E21"><apiname>HAL::Get()</apiname></xref>,

it invokes the corresponding <codeph>halFunction()</codeph> of the HAL function

group. </p></section>

</conbody></concept>