qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v1 07/16] io: add abstract QIOChannel classes
Date: Tue, 22 Sep 2015 14:28:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0


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.

Paolo



reply via email to

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