diff -r 578be2adaf3e -r 307f4279f433 Adaptation/GUID-22CCA5B5-D4AB-4ABC-94C6-CD85EC470238.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Adaptation/GUID-22CCA5B5-D4AB-4ABC-94C6-CD85EC470238.dita Fri Oct 15 14:32:18 2010 +0100 @@ -0,0 +1,86 @@ + + + + + +System +InformationThis topic describes various system information related to the +device drivers. +
Presence +of PDD

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 DLogicalDevice::iParseMask bitmask +with the KDeviceAllowPhysicalDevice flag. If this flag +is not set, then the Kernel assumes that the driver does not have a PDD.

// Logical Channel Second stage constructor +DExDriverLogicalDevice:: DExDriverLogicalDevice () + { + iParseMask = KDeviceAllowPhysicalDevice | KDeviceAllowUnit; + ... + }
+
+
Capabilities

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.

The user typically +calls the RDevice::GetCaps() function to retrieve the device +capabilities.

RDevice device; +r = device.Open(KDriverName); +if (r==KErrNone) + { + TPckgBuf<RExDriver::TUartCaps> caps; + device.GetCaps(caps); + ... + device.Close(); + }

Note: 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.

+
HAL handlers

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.

Drivers must register any HAL handlers they provide, and +de-register them when unloading. Kernel extensions do not remove their HAL +handlers.

// 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);

The arguments +to AddHalEntry() 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 THalFunc.

// 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) + { + ... + } + }

When the user calls HAL::Set() or HAL::Get(), +it invokes the corresponding halFunction() of the HAL function +group.

+ \ No newline at end of file