Re: [Qemu-devel] [PATCH v1 07/16] io: add abstract QIOChannel classes

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 02:28:25PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/09/2015 14:24, Daniel P. Berrange wrote:
> > On Tue, Sep 22, 2015 at 02:19:27PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 18/09/2015 15:19, Daniel P. Berrange wrote:
> >>> +    QIO_CHANNEL_FEATURE_FD_PASS  = (1 << 0),
> >>> +    QIO_CHANNEL_FEATURE_SHUTDOWN = (1 << 1),
> >>> +    QIO_CHANNEL_FEATURE_DELAY    = (1 << 2),
> >>> +    QIO_CHANNEL_FEATURE_CORK     = (1 << 3),
> >>
> >> TCP_NODELAY and TCP_CORK are just hints; I think it is okay to just
> >> ignore them if not supported.  You obviously disagree, so the question
> >> is why? :)
> > 
> > Well I was just trying not to second guess what future uses we might
> > have of the QIOChannel API, so I went for the approach of providing a
> > way to probe any optional features upfront. Code doesn't have to use
> > this if it doesn't want to - it can just ignore errors from the API
> > call later.
> 
> Perhaps we can get to a middle ground where you can probe them but no
> errors are reported?
> 
> Reporting errors is relatively heavyweight (g_new, possibly in a hot
> path if the corresponding feature is not supported) and in general QEMU
> never checked for the return value of socket_set_cork and
> socket_set_nodelay.
> 
> The probe, however, should also test if SOL_TCP and TCP_CORK are
> defined.  I think corking is a Linux-ism.

Having slept on it now, I think I'll just remove these two feature
flags and make the methods void with no error reporting. We can
always add feature probing back at a later date if it becomes
clearly required.

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 :|