From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ILLVK-0005o0-5G for qemu-devel@nongnu.org; Wed, 15 Aug 2007 12:13:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ILLVI-0005nS-DK for qemu-devel@nongnu.org; Wed, 15 Aug 2007 12:13:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ILLVI-0005nM-87 for qemu-devel@nongnu.org; Wed, 15 Aug 2007 12:13:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ILLVH-0002UV-Ko for qemu-devel@nongnu.org; Wed, 15 Aug 2007 12:13:51 -0400 Received: by ug-out-1314.google.com with SMTP id m2so185369uge for ; Wed, 15 Aug 2007 09:13:49 -0700 (PDT) Message-ID: Date: Wed, 15 Aug 2007 19:13:49 +0300 From: "Blue Swirl" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Qemu-devel] Extending qemu_irq for reset signals Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook , qemu-devel Hi, I'd like to use similar mechanism as qemu_irq as reset signal for devices. The difference is that the opaque data and callback are not specified at the time of creating the signal at upstream device, but when the receiving device is created. This does not fit current qemu_irq model. When you implemented qemu_irq there was some discussion about extending qemu_irq to support arbitrary signals. How should we proceed?