From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmBXm-0007y2-L1 for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:21:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmBXl-0000hU-AN for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:21:30 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:54500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmBXl-0000gx-0w for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:21:29 -0400 Message-ID: <4E308155.1040300@mail.berlios.de> Date: Wed, 27 Jul 2011 23:21:25 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1311725174-9635-1-git-send-email-aliguori@us.ibm.com> <4E307999.9080603@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] [RFC] Add glib support to main loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Amit Shah , Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org, Hans de Goede Am 27.07.2011 23:12, schrieb Blue Swirl: > On Wed, Jul 27, 2011 at 11:48 PM, Anthony Liguori wrote: > >> On 07/27/2011 03:43 PM, Blue Swirl wrote: >> >>> On Wed, Jul 27, 2011 at 3:06 AM, Anthony Liguori >>> wrote: >>> >>>> This allows GSources to be used to register callback events in QEMU. >>>> This is >>>> useful as it allows us to take greater advantage of glib and also because >>>> it >>>> allows us to write code that is more easily testable outside of QEMU >>>> since we >>>> can make use of glib's main loop in unit tests. >>>> >>>> All new code should use glib's callback mechanisms for registering fd >>>> events >>>> which are very well documented at: >>>> >>>> http://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html >>>> >>>> And: >>>> >>>> http://developer.gnome.org/gio/stable/ >>>> >>>> Signed-off-by: Anthony Liguori >>>> --- >>>> vl.c | 74 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 files changed, 74 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/vl.c b/vl.c >>>> index 4b6688b..19774ac 100644 >>>> --- a/vl.c >>>> +++ b/vl.c >>>> @@ -111,6 +111,8 @@ int main(int argc, char **argv) >>>> #define main qemu_main >>>> #endif /* CONFIG_COCOA */ >>>> >>>> +#include >>>> + >>>> #include "hw/hw.h" >>>> #include "hw/boards.h" >>>> #include "hw/usb.h" >>>> @@ -1309,6 +1311,75 @@ void qemu_system_vmstop_request(int reason) >>>> qemu_notify_event(); >>>> } >>>> >>>> +static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ >>>> +static int n_poll_fds; >>>> +static int max_priority; >>>> + >>>> +static void glib_select_fill(int *max_fd, fd_set *rfds, fd_set *wfds, >>>> + fd_set *xfds, struct timeval *tv) >>>> +{ >>>> + GMainContext *context = g_main_context_default(); >>>> + int i; >>>> + int timeout = 0, cur_timeout; >>>> + >>>> + g_main_context_prepare(context,&max_priority); >>>> + >>>> + n_poll_fds = g_main_context_query(context, max_priority,&timeout, >>>> + poll_fds, ARRAY_SIZE(poll_fds)); >>>> + g_assert(n_poll_fds<= ARRAY_SIZE(poll_fds)); >>>> >>> The use of g_assert() means that production code should define >>> G_DISABLE_ASSERT in addition to NDEBUG. Should we make both default >>> for stable versions? >>> >> Oh, this is just me being lazy. There's a way to do this without using the >> assert. I put the assert there to make sure that I didn't leave a latent >> bug. >> >> But in general, I don't think we should ever define NDEBUG. >> > Why? I think it's normal practice to define NDEBUG (and > G_DISABLE_ASSERT if g_assert() is used) for production builds. > NDEBUG is normally set automatically for production code, and it disables assertions which is not always good. Assertions are useful even in production code unless you are sure that the code is bug free or the assertions cost to much resources - either memory or execution time. I don't think this is the case for QEMU, therefore I'd prefer having assertions in production code, too. This simply means undefining NDEBUG before including assert.h. Regards, Stefan