From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeMgX-0001q9-QB for qemu-devel@nongnu.org; Tue, 22 Sep 2015 08:28:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeMgS-0002q4-Qh for qemu-devel@nongnu.org; Tue, 22 Sep 2015 08:28:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeMgS-0002pi-Kx for qemu-devel@nongnu.org; Tue, 22 Sep 2015 08:28:32 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id D2E67C0B91A3 for ; Tue, 22 Sep 2015 12:28:31 +0000 (UTC) References: <1442582350-9179-1-git-send-email-berrange@redhat.com> <1442582350-9179-8-git-send-email-berrange@redhat.com> <5601474F.2000507@redhat.com> <20150922122452.GN28888@redhat.com> From: Paolo Bonzini Message-ID: <56014969.4070603@redhat.com> Date: Tue, 22 Sep 2015 14:28:25 +0200 MIME-Version: 1.0 In-Reply-To: <20150922122452.GN28888@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 07/16] io: add abstract QIOChannel classes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Gerd Hoffmann , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" 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