Re: [Qemu-devel] [PATCH FYI 12/46] io: add QIOChannelTLS class

[Daniel P. Berrange]

On Mon, Sep 07, 2015 at 04:51:59PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (address@hidden) wrote:
> > On Mon, Sep 07, 2015 at 04:31:08PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (address@hidden) 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 <address@hidden>
> > > 
> > > > ---
> > > > +#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 :|