qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v23 06/11] libcacard: initial commit


From: Jes Sorensen
Subject: Re: [Qemu-devel] [PATCH v23 06/11] libcacard: initial commit
Date: Mon, 28 Mar 2011 15:52:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9

On 03/28/11 14:42, Alon Levy wrote:
> On Mon, Mar 28, 2011 at 02:35:23PM +0200, Jes Sorensen wrote:
>>> +/*
>>> + * NSS headers
>>> + */
>>> +#include <nss.h>
>>> +#include <pk11pub.h>
>>> +#include <cert.h>
>>> +#include <key.h>
>>> +#include <secmod.h>
>>> +#include <prthread.h>
>>> +#include <secerr.h>
>>> +
>>> +#include "qemu-common.h"
>>
>> again here
>>
>> prthread.h do you have a check for it in configure?  I have to admit I
>> really would prefer QEMU not relying on the NSPR stuff, but I don't know
>> if it can be avoided with the ccid code?
> 
> No, unless you mean I should rewrite the emulation to not use NSS, I don't 
> know
> how. Or are you saying NSS can be used without using NSPR? I admited and will
> repeat that I have not authored this code (that's why I have Robert Relyea as
> the author of this patch), so I'm not familiar with NSS/NSPR except 
> superficially.

I don't know enough about NSS to say so, so just leave it in. However,
please check that the build doesn't break if one doesn't have the nspr
headers installed.

>>> diff --git a/libcacard/vreader.c b/libcacard/vreader.c
>>> new file mode 100644
>>> index 0000000..0b67c6c
>>> --- /dev/null
>>> +++ b/libcacard/vreader.c
>>> @@ -0,0 +1,519 @@
>>> +/*
>>> + * emulate the reader
>>> + *
>>> + * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
>>> later.
>>> + * See the COPYING.LIB file in the top-level directory.
>>> + */
>>> +
>>> +/*
>>> + * System includes
>>> + */
>>> +#include <stdlib.h>
>>> +#include <string.h>
>>> +
>>> +#include "qemu-thread.h"
>>> +#include "qemu-common.h"
>>
>> and a last one....
> 
> Are these a problem enough that you will without an ack? with respect to your
> previous acks do you want me to only send this patch again, and Anthony should
> merge the acked patches?

It would be preferred to have it fixed before the patch goes in, it
should be a quick fix. I'll be happy to ack it with that change.

Cheers,
Jes



reply via email to

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