From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYyuh-0001Lw-6u for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:05:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYyue-000079-0o for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:04:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYyud-000072-QE for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:04:55 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 392CE8F265 for ; Mon, 7 Sep 2015 16:04:55 +0000 (UTC) Date: Mon, 7 Sep 2015 17:04:50 +0100 From: "Daniel P. Berrange" Message-ID: <20150907160450.GU29882@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> <20150907154116.GR29882@redhat.com> <20150907155158.GF2337@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150907155158.GF2337@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:51:59PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > 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. > > You can imagine something like compression->TLS->socket and then it gets > into the caller having to do a generic walk to figure out if it can > do it; I'd rather not have to do that in caller. > I think I'd rather it was a facility on QIOChannel and then it gets > some type of ENOTSUPP error if it hits a layer that doesn't support it; > I guess the same might be true for socket behaviours like nagling and > maybe blocking. Yeah, nagling I have defined as an API only on QIOChannelSocket. The blocking flag though was on the base QIOChannel interface. On the QIOChannel interface I did in fact provide the facility to do UNIX FD passing, which is a UNIX socket only feature, along with a feature query mechanism. So I guess I already have precedent for putting such features in the base class. So I'll update this series to move some of those methods like shutdown, nagle, cork, in the base QIOChannel interface. 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 :|