From 85c1a92dfccd61a82c75a0584ba5bff1c9e21913 Mon Sep 17 00:00:00 2001
From: short <>
Date: Fri, 17 Oct 2003 14:01:42 +0000
Subject: [PATCH] Cache Manager functionality update according to the latest
 betatests.

---
 project/captive/doc/CacheManager.html.pl | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/project/captive/doc/CacheManager.html.pl b/project/captive/doc/CacheManager.html.pl
index fcd893e..7b18551 100755
--- a/project/captive/doc/CacheManager.html.pl
+++ b/project/captive/doc/CacheManager.html.pl
@@ -103,7 +103,10 @@ print <<"HERE";
 	of memory-exceeding <span class="function">CcInitializeCacheMap()</span>
 	reservation request. <span class="function">CcSetFileSizes()</span>
 	changing the reserved memory area size may assume no existing Map
-	or Pin mappings exist.</p>
+	or Pin mappings exist. Only in the case of 
+	<span class="constant">FO_STREAM_FILE</span> (virtual device file)
+	it is permitted to extend mapped size even in the case of existing
+	(and dirty) Map or Pin mappings.</p>
 
 	<p><span class="type">PCACHE_MANAGER_CALLBACKS</type> argument can be
 	safely ignored:</p>
@@ -219,7 +222,14 @@ print <<"HERE";
 
 	<p>Only the pages not yet present in the memory must be read from the disk.
 	You must not read any pages you do not need to as the driver does not
-	expect it and it would corrupt its data buffers.</p>
+	expect it and it would corrupt its data buffers. There is just a&nbsp;strict
+	difference between <span class="function">CcPinRead()</span> and
+	<span class="function">CcPinMappedData()</span> function calls where
+	<span class="function">CcPinRead()</span> is required to re-read its data
+	blocks even if they were currently already Map mapped (unless it was already
+	also Pin mapped at least once). On the opposite side
+	<span class="function">CcPinMappedData()</span> must not re-read the given
+	blocks, moreover it blocks are required to be already Map mapped by the caller.</p>
 
 	<p>Cache Manager of this project will destroy Pin or Map mappings after
 	their last unreferencing (in opposite of
-- 
1.8.3.1