Fix some spelling bugs in documentation and comments

These errors were detected by codespell:

remaing -> remaining
soley -> solely
virutal -> virtual
seperate -> separate

libcacard.txt still needs some more patches.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This commit is contained in:
Stefan Weil 2011-11-13 22:24:27 +01:00 committed by Stefan Hajnoczi
parent b5e4946f96
commit 4238e26416
3 changed files with 5 additions and 5 deletions

View File

@ -521,7 +521,7 @@ static int is_stage2_completed(void)
if ((remaining_dirty / bwidth) <=
migrate_max_downtime()) {
/* finish stage2 because we think that we can finish remaing work
/* finish stage2 because we think that we can finish remaining work
below max_downtime */
return 1;

View File

@ -281,7 +281,7 @@ create card responses.
VCardResponse *vcard_make_response(VCard7816Status status);
This is the most basic function to get a response. This function will
return a response the consists soley one 2 byte status code. If that status
return a response the consists solely one 2 byte status code. If that status
code is defined in card_7816t.h, then this function is guarrenteed to
return a response with that status. If a cart type specific status code
is passed and vcard_make_response fails to allocate the appropriate memory
@ -327,7 +327,7 @@ and applet.
int vcard_emul_get_login_count(VCard *card);
This function returns the the number of remaing login attempts for this
This function returns the the number of remaining login attempts for this
card. If the card emulator does not know, or the card does not have a
way of giving this information, this function returns -1.
@ -373,7 +373,7 @@ functions:
The options structure is built by another function in the virtual card
interface where a string of virtual card emulator specific strings are
mapped to the options. The actual structure is defined by the virutal card
mapped to the options. The actual structure is defined by the virtual card
emulator and is used to determine the configuration of soft cards, or to
determine which physical cards to present to the guest.

View File

@ -14,7 +14,7 @@ To map QMP-defined interfaces to the native C QAPI implementations,
a JSON-based schema is used to define types and function
signatures, and a set of scripts is used to generate types/signatures,
and marshaling/dispatch code. The QEMU Guest Agent also uses these
scripts, paired with a seperate schema, to generate
scripts, paired with a separate schema, to generate
marshaling/dispatch code for the guest agent server running in the
guest.