On 12/08/2010 03:15 AM, Stefan Hajnoczi wrote:
On Tue, Dec 07, 2010 at 04:02:03PM +0100, Jes Sorensen wrote:
On 12/07/10 15:48, Michael Roth wrote:
On 12/07/2010 07:31 AM, Jes Sorensen wrote:
On 12/03/10 19:03, Michael Roth wrote:
I am not happy with this addition of numbers to these functions, it
doesn't tell us why we have a 3 and how it differs from 2. If 3 is
really the backend for implementing 2, maybe it would be better to name
it __qemu_set_fd_handler2() and then have macros/wrappers calling into
it.
That was the initial plan, but qemu_set_fd_handler2() is a back-end of
sorts for qemu_set_fd_handler(), so I was just trying to be consistent
with the naming. Personally I don't have any objections one way or the
other.
Anything to avoid qemu_set_fd_handler17() at some point. I think using
__qemu_set_fd_handler() encourages people to modify that code rather
than copy it.
I agree that qemu_set_fd_handler3() could be named something more
meaningful. Unfortunately we can't use __qemu_set_fd_handler() because
the C language standard reserves identifiers that start with double
underscore for the standard library. The Linux kernel gets away with it
because the code is freestanding but that doesn't apply to QEMU.
fdset_set_handler()
or:
iohandler_set_handler()
Take whatever the structure is that represents the global state, convert
it's name to lower case, and use that as the prefix.
If this were C++, the namespacing would be obvious because you wouldn't
have a choice about how to design the namespace ;-)
/me ducks
Regards,
Anthony Liguori
Stefan
