qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Fixing some spelling in docs/libcacard.txt


From: Alon Levy
Subject: Re: [Qemu-devel] [PATCH] Fixing some spelling in docs/libcacard.txt
Date: Tue, 15 Nov 2011 13:24:36 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Nov 15, 2011 at 11:57:14AM +0000, address@hidden wrote:
> From: Matthias Brugger <address@hidden>
> 

Thanks!

Reviewed-by: Alon Levy <address@hidden>

> 
> Signed-off-by: Matthias Brugger <address@hidden>
> ---
>  docs/libcacard.txt |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/libcacard.txt b/docs/libcacard.txt
> index 5dee6fa..576af57 100644
> --- a/docs/libcacard.txt
> +++ b/docs/libcacard.txt
> @@ -170,7 +170,7 @@ public entry point:
>                                 int cert_count);
>  
>    The parameters for this are:
> -  card       - the virtual card structure which will prepresent this card.
> +  card       - the virtual card structure which will represent this card.
>    flags      - option flags that may be specific to this card type.
>    cert       - array of binary certificates.
>    cert_len   - array of lengths of each of the certificates specified in 
> cert.
> @@ -179,7 +179,7 @@ public entry point:
>    cert_count - number of entries in cert, cert_len, and key arrays.
>  
>    Any cert, cert_len, or key with the same index are matching sets. That is
> -  cert[0] is cert_len[0] long and has the corresponsing private key of 
> key[0].
> +  cert[0] is cert_len[0] long and has the corresponding private key of 
> key[0].
>  
>  The card type emulator is expected to own the VCardKeys, but it should copy
>  any raw cert data it wants to save. It can create new applets and add them to
> @@ -261,7 +261,7 @@ Prior to processing calling the card type emulator's 
> VCardProcessAPDU function,
>     apdu->a_Le   - The expected length of any returned data.
>     apdu->a_cla  - The raw apdu class.
>     apdu->a_channel - The channel (decoded from the class).
> -   apdu->a_secure_messaging_type - The decoded secure messagin type
> +   apdu->a_secure_messaging_type - The decoded secure messaging type
>                                     (from class).
>     apdu->a_type - The decode class type.
>     apdu->a_gen_type - the generic class type (7816, PROPRIETARY, RFU, PTS).
> @@ -273,7 +273,7 @@ Creating a Response --
>  
>  The expected result of any APDU call is a response. The card type emulator 
> must
>  set *response with an appropriate VCardResponse value if it returns 
> VCARD_DONE.
> -Reponses could be as simple as returning a 2 byte status word response, to as
> +Responses could be as simple as returning a 2 byte status word response, to 
> as
>  complex as returning a block of data along with a 2 byte response. Which is
>  returned will depend on the semantics of the APDU. The following functions 
> will
>  create card responses.
> @@ -282,12 +282,12 @@ create card responses.
>  
>      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
> -    code is defined in card_7816t.h, then this function is guarrenteed to
> +    code is defined in card_7816t.h, then this function is guaranteed 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
>      for that response, then vcard_make_response will return a VCardResponse
>      of VCARD7816_STATUS_EXC_ERROR_MEMORY. In any case, this function is
> -    guarrenteed to return a valid VCardResponse.
> +    guaranteed to return a valid VCardResponse.
>  
>          VCardResponse *vcard_response_new(unsigned char *buf, int len,
>                                            VCard7816Status status);
> -- 
> 1.7.1
> 
> 



reply via email to

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