From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3NPd-00049O-PD for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:32:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3NPZ-0005yp-Js for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:32:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3NPZ-0005yX-Aj for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:32:37 -0400 Message-ID: <5031F620.1020805@redhat.com> Date: Mon, 20 Aug 2012 10:32:32 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1740071682.16529215.1345449641615.JavaMail.root@redhat.com> In-Reply-To: <1740071682.16529215.1345449641615.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 1.2] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: Blue Swirl , qemu-devel@nongnu.org On 08/20/12 10:00, Alon Levy wrote: >> Hi, >> >>>>> +#ifndef QXL_HAS_IO_MONITORS_CONFIG_ASYNC +#define >>>>> QXL_HAS_IO_MONITORS_CONFIG_ASYNC 0 >>>> >>>> Just delete this and use >>>> defined(QXL_HAS_IO_MONITORS_CONFIG_ASYNC). >>> >>> So you are telling me to undo a change that Gerd asked for - >>> could you please at least debate about the merits of both >>> approaches? the point of having QXL_HAS_IO_MONITORS_CONFIG_ASYNC >>> always defined was to allow usage of #if without defined, which >>> is shorter. >> >> Hmm? That wasn't that I meant, must have been a tyops. I mean you >> should just do ... >> >> #ifndef QXL_IO_MONITORS_CONFIG_ASYNC <--- without >> *_HAS_* #define QXL_IO_MONITORS_CONFIG_ASYNC $value #endif >> >> then you don't need QXL_HAS_IO_MONITORS_CONFIG_ASYNC (and all the >> #ifdefs) at all ... > > So you want me to give the io a value Well, it has one, right? [ checking spice-protocol ] It's 24. > - at this point I'd rather just add spice-protocol as a submodule, > then we don't need to do any of this. How about it? No. You can build qemu without submodules today as they are used for ROMS only (which are also provided as precompiled binaries). Maybe revisit upstream spice packaging? spice internal usage of spice-protocol is handled via submodules now. Are there external users, other than qemu? Does it make sense to keep the spice-server / spice-protocol split in the first place? Or should spice-server just provide the protocol headers too? cheers, Gerd