From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYyXt-00025g-DW for qemu-devel@nongnu.org; Mon, 07 Sep 2015 11:41:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYyXp-0006Nx-PZ for qemu-devel@nongnu.org; Mon, 07 Sep 2015 11:41:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYyXp-0006Nn-KT for qemu-devel@nongnu.org; Mon, 07 Sep 2015 11:41:21 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 33624C0B9867 for ; Mon, 7 Sep 2015 15:41:21 +0000 (UTC) Date: Mon, 7 Sep 2015 16:41:16 +0100 From: "Daniel P. Berrange" Message-ID: <20150907154116.GR29882@redhat.com> References: <1441294768-8712-1-git-send-email-berrange@redhat.com> <1441294768-8712-13-git-send-email-berrange@redhat.com> <20150907153107.GD2337@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150907153107.GD2337@work-vm> Subject: Re: [Qemu-devel] [PATCH FYI 12/46] io: add QIOChannelTLS class Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Juan Quintela , qemu-devel@nongnu.org, Gerd Hoffmann , Amit Shah , Paolo Bonzini On Mon, Sep 07, 2015 at 04:31:08PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > Add a QIOChannel subclass that can run the TLS protocol over > > the top of another QIOChannel instance. The object provides a > > simplified API to perform the handshake when starting the TLS > > session. The layering of TLS over the underlying channel does > > not have to be setup immediately. It is possible to take an > > existing QIOChannel that has done some handshake and then swap > > in the QIOChannelTLS layer. This allows for use with protocols > > which start TLS right away, and those which start plain text > > and then negotiate TLS. > > > > Signed-off-by: Daniel P. Berrange > > > --- > > +#ifdef QIO_DEBUG > > +#define DPRINTF(fmt, ...) do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0) > > +#else > > +#define DPRINTF(fmt, ...) do { } while (0) > > +#endif > > Can you use the trace_ stuff rather than dprintf's; I've been trying > to remove them all from the migration code (and with trace configured in > stderr mode it works pretty easily). Yeah, that's a good idea. > On a different question; if this TLS channel is backed by a socket, can I do > a shutdown call that will bubble down to the socket? The QIOChannel abstract base class did not define any shutdown method, since that's not a generally applicable concept - essentially only the sockets interface can do that. So I defined it as a method just on the QIOChannelSocket class. Given this, the QIOChannelTLS class does not know about the shutdown call. This isn't a big deal though - the QIOChannelTLS struct exposes a pointer to the underling QIOChannel transport, so code that needs to do a shutdown, can get hold of the underlying channel and call shutdown on that. I forgot to do this properly when I integrated with the migration QEMUFile interface, so I'll fix that up, so shutdown works correctly with migration when TLS is enabled. Regards, Daniel -- |: 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 :|