[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-trivial] [Qemu-devel] [PATCH] Fixing some spelling in docs/lib
From: |
Alon Levy |
Subject: |
Re: [Qemu-trivial] [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
>
>