From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuuFk-0004or-Um for qemu-devel@nongnu.org; Thu, 25 Mar 2010 17:06:09 -0400 Received: from [140.186.70.92] (port=39453 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuuFi-0004mG-Nv for qemu-devel@nongnu.org; Thu, 25 Mar 2010 17:06:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuuFh-000277-A5 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 17:06:06 -0400 Received: from mx20.gnu.org ([199.232.41.8]:52866) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuuFh-000273-8X for qemu-devel@nongnu.org; Thu, 25 Mar 2010 17:06:05 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NuuFg-0000xS-KL for qemu-devel@nongnu.org; Thu, 25 Mar 2010 17:06:04 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [patch 1/2] Pass QEMUIOWorker to qemu_notify_event Date: Thu, 25 Mar 2010 21:06:00 +0000 References: <20100325134715.354365213@amt.cnet> <20100325134957.646980309@amt.cnet> In-Reply-To: <20100325134957.646980309@amt.cnet> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003252106.01194.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: amit.shah@redhat.com, Anthony Liguori , Marcelo Tosatti > /* Force QEMU to process pending events */ > -void qemu_notify_event(void); > +void qemu_notify_event(QEMUIOWorker *worker); > static void handle_input(VirtIODevice *vdev, VirtQueue *vq) > { > + qemu_notify_event(main_io_worker); > } This feels completely wrong. Devices shouldn't know or care about implementation details like this. How is a device supposed to know which worker it should be waking up? qemu_notify_event is an ugly hack to workaround the fact that our character device API is polled. If shouldn't exist in the first place, instead we should have a proper mechanism for device emulation to notify the CharDriverState when it is ready to recieve more data. Paul