l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

patch for typos in doc/vmm.tex


From: Ludovic Courtès
Subject: patch for typos in doc/vmm.tex
Date: Thu, 13 Nov 2003 17:08:10 +0100
User-agent: Mutt/1.5.4i [Guile enabled]

Hi,

Here is another patch for small typos in doc/vmm.tex .  Note that it may
be worth proof-reading it since I'm not a native speaker, nor am I very
familiar with the VMM design.

Thanks,
Ludovic.

--- vmm.tex.20030930    2003-11-13 16:48:01.000000000 +0100
+++ vmm.tex     2003-11-13 17:01:55.000000000 +0100
@@ -23,3 +23,3 @@
 resources at any given time.  As can be imagined, the policy to access
-and the mechanisms to use these resources determines many important
+and the mechanisms to use these resources determine many important
 characteristics of the system.
@@ -77,3 +77,3 @@
 The system must attempt to meet a given allocation criteria.  However,
-as the kernel does not and cannot know how how a task will use its
+as the kernel does not and cannot know how a task will use its
 memory except based on the use of page fault statistics is bound to
@@ -99,3 +99,3 @@
 
-Based on this observation, it is imperitive that the page eviction
+Based on this observation, it is imperative that the page eviction
 scheme have good knowledge about how pages are being used as it only
@@ -104,3 +104,3 @@
 even more knowledge to the kernel to increase performance or the page
-eviction scheme can be remove from the kernel completely and placed in
+eviction scheme can be removed from the kernel completely and placed in
 user space and make all tasks self paged.
@@ -171,4 +171,4 @@
 memory and make applications completely self-paged.  Thus, the burden
-of paging lies the application themselves.  When application request
-memory, they no longer request virutal memory but physical memory.
+of paging lies the application themselves.  When applications request
+memory, they no longer request virtual memory but physical memory.
 Once the application has exhausted its available frames, it is its
@@ -179,5 +179,5 @@
 POSIX personality.  This should not, however, be hard coded: certain
-application may greatly benefit by being able to control their own
+applications may greatly benefit by being able to control their own
 eviction schemes.  At its most basic level, hints could be provided to
-the manager by introducing extentions on basic function calls.  For
+the manager by introducing extensions on basic function calls.  For
 instance, \function{malloc} could take an extra parameter indicating
@@ -220,3 +220,3 @@
 the frame becomes dirty being careful to never have less than $E$
-clean frames in the task.  Given these semantics, guanteed frames
+clean frames in the task.  Given these semantics, guaranteed frames
 should not be thought of as wired (e.g. \function{mlock}ed in the
@@ -274,3 +274,3 @@
 over commit the number of frames, i.e. the total number of guaranteed
-frames must never exceed the number of frames avilable for allocation.
+frames must never exceed the number of frames available for allocation.
 
@@ -320,3 +320,3 @@
 In a multiserver system, most data acquisitions come from user space
-servers.  As such, powerful primatives for moving memory around is an
+servers.  As such, powerful primitives for moving memory around is an
 absolute necessity: physical copying must be kept to an absolute
@@ -504,3 +504,3 @@
 immediately as the underlying physical frames may have to be allocated
-in which case the physical memory server may have to be reap physical
+in which case the physical memory server may have to reap physical
 pages from other tasks' extra frame allocations.
@@ -508,3 +508,3 @@
 The physical memory server may unmap pages at any time.  This allows
-the physical memory server to fucntionally lock the contents of the
+the physical memory server to functionally lock the contents of the
 frame and move it to a new physical frame.  As such, tasks must be
@@ -526,3 +526,3 @@
 \noindent
-Flags may is a bitwise or of: \constant{CONT\_MAP\_READ},
+\variable{flags} is a bitwise or of: \constant{CONT\_MAP\_READ},
 \constant{CONT\_MAP\_WRITE} and \constant{CONT\_MAP\_FORCE\_WRITE}.
@@ -540,3 +540,3 @@
 error\_t pm\_container\_create\_with (out container\_t container, in
-in int frame\_count, out container\_t weak\_ref)
+int frame\_count, out container\_t weak\_ref)
 \end{code}
@@ -561,3 +561,3 @@
 important technique for sharing executable and shared library text.  A
-family of functions are available which logically copies the contents
+family of functions is available which logically copies the contents
 of one container to another:
@@ -588,6 +588,6 @@
 
-If a frame does not exist in the source, ENOENT.  If a frame does not
-exist in the destination, ENOMEM is returned.  In both cases, the
-frame identifier causing the error is returned in
-\variable{frame\_error}.
+If a frame does not exist in the source, \constant{ENOENT} is
+returned.  If a frame does not exist in the destination,
+\constant{ENOMEM} is returned.  In both cases, the frame identifier
+causing the error is returned in \variable{frame\_error}.
 
@@ -690,3 +690,3 @@
 keep the device driver in question in a small address space (an
-important optimization on architectures without tagged TLBs, table
+important optimization on architectures without tagged TLBs, translation
 look aside buffers).  Second, if both the file system and the device
@@ -708,3 +708,3 @@
 cache is smart and chooses the better frames to evict, the
-cooresponding physical frames will not really be freed until the
+corresponding physical frames will not really be freed until the
 device driver also drops its references to the frames.  Thus, the
@@ -797,3 +797,3 @@
 When a task reaches its guaranteed frame allocation, it must begin to
-reuse its available virtual frames.  If the data is frames is precious
+reuse its available virtual frames.  If the data in these frames is precious
 (i.e. not easliy constructed by e.g. a calculation or by rereading a
@@ -812,3 +812,3 @@
 frame is sent to swap).  If this was not the case, then when a number
-of tasks all with a reference to a given physical send the frame to
+of tasks all with a reference to a given physical frame send the frame to
 swap, the swap server would allocate and write N times as opposed to
@@ -817,4 +817,4 @@
 
-Frame may not be sent to swap immediately.  Instead, they are kept on
-an inactive list allowing thereby allowing a task to recover the
+Frames may not be sent to swap immediately.  Instead, they are kept on
+an inactive list thereby allowing a task to recover the
 contents of a frame before it is flushed to swap (that is to say, swap
@@ -825,3 +825,3 @@
 before the frame is reused to prevent gratuitous copy on writes from
-begin performed.  It also important to call this function if the frame
+being performed.  It is also important to call this function if the frame
 was being used for shared memory.
@@ -833,3 +833,3 @@
 As already explained, tasks are self-paged.  The default
-implementation provided with the hurd has each thread in a task set
+implementation provided with the Hurd has each thread in a task set
 its pager (i.e. its fault handler) to a common pager thread in the
@@ -865,3 +865,3 @@
 instance, routines to manipulate capabilities, this text must be
-backed by the final pager.  Other code can also, however, makes calls
+backed by the final pager.  Other code can also, however, make calls
 to the capability library.  This means that the primary pager must
@@ -885,7 +885,7 @@
 of creating a few entries in the mapping database so that faults will
-brings the data in lazily.
+bring the data in lazily.
 
 Rather than have the caller manipulate the mapping database directly,
-instead, a local ipc sent to the primary pager.  If there is only ever
-a single thread which manipulates the mapping database, there will be
+instead, a local ipc is sent to the primary pager.  If there is only ever
+a single thread which manipulates the mapping database, there will be no
 locking requirements.  If the pager thread is busy, then the local ipc
@@ -897,3 +897,3 @@
 into memory and then proceed to use or at least copy the data to some
-other location.  Clearly, the faulting the pages in is a waste.  As
+other location.  Clearly, faulting the pages in is a waste.  As
 such, the pager should provide a mechanism which allows the caller to
@@ -906,3 +906,3 @@
 order to reuse the frame for something else.  The frame itself must be
-cleared, i.e. disassocitated with any logical copies.  This is done
+cleared, i.e. disassociated from any logical copies.  This is done
 using:





reply via email to

[Prev in Thread] Current Thread [Next in Thread]