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
