qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [RFC][PATCH v5 01/21] Move code related to fd handl


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v5 01/21] Move code related to fd handlers into utility functions
Date: Wed, 8 Dec 2010 09:15:14 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

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.

Stefan



reply via email to

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