[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v1 RFC 08/34] crypto: introduce new module for c

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v1 RFC 08/34] crypto: introduce new module for computing hash digests
Date: Wed, 13 May 2015 18:21:19 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, May 13, 2015 at 07:12:32PM +0200, Paolo Bonzini wrote:
> On 13/05/2015 19:04, Daniel P. Berrange wrote:
> > I'm thinking perhaps a better approach could be for the crypto related
> > APIs to call qcrypto_init() on an as-needed basis. The downside would
> > be that this could delay the point at which the user sees a gnutls
> > initialization failure to only after QEMU has been running for a while,
> > instead of being upfront at startup. The plus side is obviously that
> > we'd not need to update every binary program main() method.
> > 
> > I notice though that QEMU does not make use of pthread_once() for
> > global initializers. Is there any particular reason for this ? With
> > this crypto code it is not safe to rely on being single threaded,
> > since the crypto code can be invoked from I/O threads as well as
> > the main event loop. So ideally I would use a pthread_once() instead
> > of having a static 'bool is_initialized' protected by a pthread_mutex
> Yes---though you'd use a GOnce instead for portability.
> In fact you would likely keep both, and use a GOnce from qcrypto_init.
> Then you can always call qcrypto_init from main if that helps making
> early failures clearer.

Ok, I'll go with GOnce and keep an init call in vl.c for clear error

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

reply via email to

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