qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 0/9] Clear fd handlers


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 0/9] Clear fd handlers
Date: Wed, 10 Mar 2010 01:12:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> On 03/09/2010 05:53 PM, malc wrote:
>> On Tue, 9 Mar 2010, Juan Quintela wrote:
>>> - convert io_handlers to one QLIST

This part removes lines :)

>>> - once there fix bt that don't need poll at all (having a poll function 
>>> that always return true
>>>    is the equivalent of not having one).

This one also removes lines.

>>> - remove cast to (void *)(unsigned long) for things that already
>>> were pointers

Cleanup. same lines.

>>> - IOCanRWHandler is only used for reads ->  rename it (almost no users).

cleanup. same lines.

>>> ToDo:
>>> - to remove the export of qemu_set_fd_handlers2() we need a solution for 
>>> tap.
>>>    Tap is the only user in qemu that uses poll, read and write, and it 
>>> changes in very imaginative
>>>    ways:
>>>      qemu_set_fd_handler2(s->fd,
>>>                           s->read_poll  ? tap_can_send : NULL,
>>>                           s->read_poll  ? tap_send     : NULL,
>>>                           s->write_poll ? tap_writable : NULL,
>>>                           s);
>>>
>>>    No ideas about how to transform this into something that don't use 
>>> NULL's in any of its fields
>>>    other than a row of if's.

for removing the poll function.  I need some help here.

>>>
>>> - removal of poll function. comment of qemu_set_fd_handler2()
>>>    /* XXX: fd_read_poll should be suppressed, but an API change is
>>>      necessary in the character devices to suppress fd_can_read(). */
>>>
>>>    But qemu-char.c is a complex beast, and would preffer to 1st get this 
>>> patches in, and then
>>>    work on the other stuff.

on that one looking at it, but it has at least two indirections.  Only 4
users left here.  Will try to look at it.

>>>
>> What's the point if it ends up adding 48 lines of code?
>>

readability? I got confused continously with:

qemu_set_fd_handler2(s->fd, NULL, foo, NULL, state);
qemu_set_fd_handler2(s->fd, NULL, NULL, bar, state);

And not all functions name make clear than foo means read and bar means write.

> Yeah, I think this would be more interesting if it eliminated the
> can_read handlers altogether.

Fully, agree. Indirections of qemu-char.c are "interesting".  tap is
only user of poll, read and write and the only one that adds/remove
functions continously.

Was waiting for tips, hints, past ideas about how to remove that fd_can 
funtions.

Regards, Juan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]