--- a/Symbian3/PDK/Source/GUID-204B4155-AE35-5C53-867B-299AF7E5D16A.dita	Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-204B4155-AE35-5C53-867B-299AF7E5D16A.dita	Fri Aug 13 16:47:46 2010 +0100
@@ -1,31 +1,31 @@
-<?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-204B4155-AE35-5C53-867B-299AF7E5D16A" xml:lang="en"><title>Device
-driver services</title><shortdesc>Describes asynchronous services provided by device drivers.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>Some asynchronous services are provided directly by device drivers.</p>
-<p>As with services provided by the client-server framework, device driver
-provided services are presented to clients through a client API known as the
-user-side device driver. This is typically an <codeph>R</codeph> class, derived
-from <codeph>RLogicalChannel</codeph>. </p>
-<p>When the <codeph>RLogicalChannel</codeph> is opened, the device driver
-is initialised and the client’s thread id is noted. Request functions are
-converted into a message which encapsulates all the parameters, and sent to
-the Kernel-side driver. Completion of a request function usually corresponds
-closely with completion of a device operation. On completion, the driver posts
-the request status and signals the client thread’s request semaphore.</p>
-<p>Device drivers often have limited capability. For instance, an inability
-to be opened by multiple client threads simultaneously. Therefore, devices
-are often handled by specially tailored server threads. These servers present
-a client API with more sophistication, sharing and checking. </p>
-<p>Usually, therefore, clients use the server-provided classes rather than
-the user-side device driver directly.</p>
+<?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-204B4155-AE35-5C53-867B-299AF7E5D16A" xml:lang="en"><title>Device
+driver services</title><shortdesc>Describes asynchronous services provided by device drivers.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Some asynchronous services are provided directly by device drivers.</p>
+<p>As with services provided by the client-server framework, device driver
+provided services are presented to clients through a client API known as the
+user-side device driver. This is typically an <codeph>R</codeph> class, derived
+from <codeph>RLogicalChannel</codeph>. </p>
+<p>When the <codeph>RLogicalChannel</codeph> is opened, the device driver
+is initialised and the client’s thread id is noted. Request functions are
+converted into a message which encapsulates all the parameters, and sent to
+the Kernel-side driver. Completion of a request function usually corresponds
+closely with completion of a device operation. On completion, the driver posts
+the request status and signals the client thread’s request semaphore.</p>
+<p>Device drivers often have limited capability. For instance, an inability
+to be opened by multiple client threads simultaneously. Therefore, devices
+are often handled by specially tailored server threads. These servers present
+a client API with more sophistication, sharing and checking. </p>
+<p>Usually, therefore, clients use the server-provided classes rather than
+the user-side device driver directly.</p>
 </conbody></concept>
\ No newline at end of file