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

[Anthony Liguori]

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
>