From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7oAG-0002UA-MW for qemu-devel@nongnu.org; Fri, 09 Aug 2013 10:59:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7oAA-0001v3-Iy for qemu-devel@nongnu.org; Fri, 09 Aug 2013 10:59:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7oAA-0001uf-Bg for qemu-devel@nongnu.org; Fri, 09 Aug 2013 10:59:34 -0400 Message-ID: <520503AE.3030606@redhat.com> Date: Fri, 09 Aug 2013 16:58:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1375998147-24292-1-git-send-email-alex@alex.org.uk> <1375998147-24292-14-git-send-email-alex@alex.org.uk> <5204BF28.6000800@redhat.com> <685383E9-AA6D-4CDC-883B-92229FF601D1@alex.org.uk> <5204FE82.6080802@redhat.com> <5F6D944D-F5B9-4A01-9828-8EB3A4B92093@alex.org.uk> <52050208.2060201@redhat.com> <6C95CA8E-5779-45EB-ACBB-B3C7FDC51721@alex.org.uk> In-Reply-To: <6C95CA8E-5779-45EB-ACBB-B3C7FDC51721@alex.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] [PATCHv8 13/30] aio / timers: Add aio_timer_new wrapper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Kevin Wolf , Anthony Liguori , liu ping fan , qemu-devel@nongnu.org, Stefan Hajnoczi , MORITA Kazutaka , rth@twiddle.net Il 09/08/2013 16:57, Alex Bligh ha scritto: > > On 9 Aug 2013, at 15:51, Paolo Bonzini wrote: > >>> One nit: >>> >>> Currently struct QEMUTimer lives nicely within qemu_timer.c, hidden >>> from the .h, which only contains: >>> typedef struct QEMUTimer QEMUTimer; >>> >>> If what you are after is for people to put a QEMUTimer into their >>> struct, rather than a QEMUTimer * (and hopefully to remember to >>> put qemu_timer_init in!) then I need to move the whole of the >>> declaration of the struct to the .h file which is a bit yucky. >> >> Yeah, that's fine. We're not relying too much on opaque types anyway. > > Out of interest, there was some talk about modular block drivers > (i.e. loading them at run time). If we do that, we'll need a stable > API, and this would be a move in the wrong direction. That's not a problem, there is absolutely no interest in out-of-tree drivers and in having a stable ABI. Paolo