From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Nez-0006zF-Ii for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:48:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3Ney-0002Fj-DQ for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:48:33 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:48477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Ney-0002FU-5J for qemu-devel@nongnu.org; Mon, 20 Aug 2012 04:48:32 -0400 Date: Mon, 20 Aug 2012 04:48:31 -0400 (EDT) From: Alon Levy Message-ID: <1102887745.16546679.1345452511180.JavaMail.root@redhat.com> In-Reply-To: <5031F620.1020805@redhat.com> MIME-Version: 1.0 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: Gerd Hoffmann Cc: 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. Yes, I'll define it as (the_previous_one + 1). > > > - 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). Makes sense, I misunderstood the use of the submodules in qemu. > > 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? spice-server is a much larger project then spice-protocol. The agents and the drivers don't need any bits in spice-server. Sure, we can unify them - it would make it easier for qemu and Xspice (the only other external user). But submodule usage would be harder then. I actually like the current submodularization of spice-protocol - it's a small header only repository that is fast to fetch. > > cheers, > Gerd > >