@@ -539,13 +539,13 @@ The type definition of the function are as follow:
### .livepatch.xen_depends, .livepatch.depends and .note.gnu.build-id
To support dependencies checking and safe loading (to load the
-appropiate payload against the right hypervisor) there is a need
-to embbed an build-id dependency.
+appropriate payload against the right hypervisor) there is a need
+to embed a build-id dependency.
This is done by the payload containing sections `.livepatch.xen_depends`
and `.livepatch.depends` which follow the format of an ELF Note.
The contents of these (name, and description) are specific to the linker
-utilized to build the hypevisor and payload.
+utilized to build the hypervisor and payload.
If GNU linker is used then the name is `GNU` and the description
is a NT_GNU_BUILD_ID type ID. The description can be an SHA1
@@ -639,7 +639,7 @@ The `name` could be an UUID that stays fixed forever for a given
payload. It can be embedded into the ELF payload at creation time
and extracted by tools.
-The return value is zero if the payload was succesfully uploaded.
+The return value is zero if the payload was successfully uploaded.
Otherwise an -XEN_EXX return value is provided. Duplicate `name` are not supported.
The `payload` is the ELF payload as mentioned in the `Payload format` section.
@@ -317,7 +317,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
process the actual like the steps below. This thread has the purpose of
aggregating as much copies as possible.]
-2) Checks if there are enough rx ring slots that can accomodate the packet.
+2) Checks if there are enough rx ring slots that can accommodate the packet.
3) Gets a request from the ring for the first data slot and fetches the `gref`
from it.
@@ -375,7 +375,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
24) Call packet into the network stack.
-25) Allocate new pages and any necessary packet metadata strutures to new
+25) Allocate new pages and any necessary packet metadata structures to new
requests. These requests will then be used in step 1) and so forth.
26) Update the request producer index (`req_prod`)
@@ -391,7 +391,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
This proposal aims at replacing step 4), 12) and 22) with memcpy if the
grefs on the Rx ring were requested to be mapped by the guest. Frontend may use
-strategies to allow fast recycling of grants for replinishing the ring,
+strategies to allow fast recycling of grants for replenishing the ring,
hence letting Domain-0 replace the grant copies with memcpy instead, which is
faster.
@@ -400,8 +400,8 @@ would need to aggregate as much as grant ops as possible (step 1) and could
transmit the packet on the transmit function (e.g. Linux ```ndo_start_xmit```)
as previously proposed
here\[[0](http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01504.html)\].
-This would heavily improve efficiency specifially for smaller packets. Which in
-return would decrease RTT, having data being acknoledged much quicker.
+This would heavily improve efficiency specifically for smaller packets. Which in
+return would decrease RTT, having data being acknowledged much quicker.
\clearpage
@@ -11,7 +11,7 @@ Raw buffer as hex string:
%*phN 000102 ... 3f
Up to 64 characters. Buffer length expected via the field_width
- paramter. i.e. printk("%*ph", 8, buffer);
+ parameter. i.e. printk("%*ph", 8, buffer);
Bitmaps (e.g. cpumask/nodemask):
While skimming through the misc docs, I spotted a few typos. Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com> --- docs/misc/livepatch.pandoc | 8 ++++---- docs/misc/netif-staging-grants.pandoc | 10 +++++----- docs/misc/printk-formats.txt | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-)