From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nkepg-0004bc-WD
	for qemu-devel@nongnu.org; Thu, 25 Feb 2010 09:36:53 -0500
Received: from [199.232.76.173] (port=41495 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nkepg-0004bG-Hw
	for qemu-devel@nongnu.org; Thu, 25 Feb 2010 09:36:52 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <kraxel@redhat.com>) id 1Nkepf-0005UO-6v
	for qemu-devel@nongnu.org; Thu, 25 Feb 2010 09:36:52 -0500
Received: from mx1.redhat.com ([209.132.183.28]:54893)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Nkepe-0005UJ-Hq
	for qemu-devel@nongnu.org; Thu, 25 Feb 2010 09:36:50 -0500
Message-ID: <4B868AFC.3060904@redhat.com>
Date: Thu, 25 Feb 2010 15:36:44 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/4] kbd leds: infrastructure
References: <1267087161-15204-1-git-send-email-kraxel@redhat.com>
	<1267087161-15204-2-git-send-email-kraxel@redhat.com>
	<4B8685EC.20000@codemonkey.ws>
In-Reply-To: <4B8685EC.20000@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

On 02/25/10 15:15, Anthony Liguori wrote:
> But I wonder if it really makes sense to treat all of these things
> differently since we end up duplicating a lot of code. Would it make
> more sense to just introduce:

> typedef struct QEMUInputHandler {
> void (*put_kbd_event)(QEMUInputHandler *obj, int keycode);
> void (*put_led_event)(QEMUInputHandler *obj, int ledstate);
> void (*put_mouse_event)(QEMUInputHandler *obj, int dx, int dy, int dz,
> int buttons_state);
> QLIST_ENTRY(QEMUInputHandler) node;
> } QEMUInputHandler;

> void qemu_add_input_handler(QEMUInputHandler *handler);
> void qemu_remove_input_handler(QEMUInputHandler *handler);

I don't think so.  Devil is in the details.  Note that kbd_event and 
mouse_event go to the kbd/mouse drivers, whereas led_event comes from 
the kbd driver, so they are different albeit related beasts.  Also the 
mouse register/unregister does some extra care to update the pointer to 
the current mouse device, so we can't easily unify the list management.

Juan's suggestion to use QLISTs makes alot of sense though, will do that.

cheers,
   Gerd