Avi Kivity <[email protected]> writes:
> On 10/04/2012 04:05 PM, Anthony Liguori wrote:
>> Avi Kivity <[email protected]> writes:
>>
>>> Many listeners don't need to respond to all MemoryListener callbacks;
>>> provide suitable defaults instead.
>>>
>
>>> +#define MEMORY_LISTENER_DEFAULT_OPS \
>>> + .begin = memory_listener_default_global, \
>>> + .commit = memory_listener_default_global, \
>>> + .region_add = memory_listener_default_section, \
>>> + .region_del = memory_listener_default_section, \
>>> + .region_nop = memory_listener_default_section, \
>>> + .log_start = memory_listener_default_section, \
>>> + .log_stop = memory_listener_default_section, \
>>> + .log_sync = memory_listener_default_section, \
>>> + .log_global_start = memory_listener_default_global, \
>>> + .log_global_stop = memory_listener_default_global, \
>>> + .eventfd_add = memory_listener_default_eventfd, \
>>> + .eventfd_del = memory_listener_default_eventfd \
>>> +
>>> +void memory_listener_default_global(MemoryListener *listener);
>>> +void memory_listener_default_section(MemoryListener *listener,
>>> + MemoryRegionSection *section);
>>> +void memory_listener_default_eventfd(MemoryListener *listener,
>>> + MemoryRegionSection *section,
>>> + bool match_data, uint64_t data,
>>> EventNotifier *e);
>>> +
>>> /**
>>> * memory_region_init: Initialize a memory region
>>> *
>>
>> I think it'd be nicer to check for NULL when invoking the functions in
>> the memory core.
>>
>> Then you avoid the exported stub functions entirely.
>
> Yes, that's the common style, but I happen not to like the extra check,
> both from a performance point of view (doesn't apply here of course) and
> from a readability point of view.
The trouble with your approach is that it introduced a subtle behavior
based on ordering. IOW:
MemoryListenerOps foo = {
MEMORY_LISTENER_DEFAULT_OPS,
.log_sync = ...,
};
vs.
MemoryListenerOps foo = {
.log_sync = ...,
MEMORY_LISTENER_DEFAULT_OPS,
};
Both compile fine but have potentially difficult to debug differences.
Relying on zero-initialization eliminates the possibility of this problem.
Regards,
Anthony Liguori
>
> --
> error compiling committee.c: too many arguments to function
