Re: [Qemu-devel] Re: [RFC][PATCH v5 01/21] Move code related to fd handlers into utility functions

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

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
>