Re: unmap() sometimes unmaps more pages than specified

On Nov 17, 2006, at 9:45 AM, Espen Skoglund wrote:

> [Espen Skoglund]
>> You have two spaces A and B.  A has a 4MB page mapping.  B has
>> received a 4KB page mapping from A.  Currently we have:
>
>>   (1)  A.Flush(4K) == A.Flush(4M) since A has a 4MB mapping.
>>   (2)  Likewise A.Unmap(4K) == A.Unmap(4M) since A has a 4MB mapping.
>>   (3)  B.Flush(4K) is fine since B has a 4KB mapping.
>>   (4)  Consequently A.Unmap(4K) != B.Flush(4K).
>
>> I guess (4) is what you find difficult to handle, right?  This would
>> work fine if (2) was not the case.  Currently the implementation
>> does (obviously) not behave this way.  I'll give some thought to how
>> this could most easily be handled.  The behaviour also raises some
>> questions about the semantics of resetting/reading reference bits,
>> but I think this could possibly be sorted out.
>
> FYI: Just implemented this a couple of days ago, and Jan has been
> pushing this (and a bunch of other updates) to the public.  What we
> have now is:  A.Unmap(4K) == B.Flush(4K).

Does this mean that the limitation described in the second paragraph  
of section 4.1 of the reference manual no longer exists?  ("Mapped  
fpages are considered inseparable objects." ...)

Is there a version of the reference manual available that reflects  
what is currently in CVS?

Josh