[Top][All Lists]

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

Re: [Qemu-devel] Re: [PATCH 1/7] Add support for generic notifier lists

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 1/7] Add support for generic notifier lists
Date: Thu, 11 Mar 2010 15:42:03 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

On 03/11/2010 03:25 PM, Paolo Bonzini wrote:
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
>  +{
>  +    void (*notify)(QEMUNotifier *notifier);
>  +};

I suggest combining this with QEMUBH.

I didn't understand this suggestion exactly, but I think it's related that I didn't understand the advantage of making QEMUNotifier a struct. Instead of using container_of, reusing QEMUBHFunc (renamed to QEMUCallbackFunc maybe?) in QEMUNotifierNode like this:

    struct QEMUNotifierNode {
        QEMUCallbackFunc notify;
        void *opaque;
        QTAILQ_ENTRY(QEMUNotifierNode) node;

    void qemu_notifier_list_init(QEMUNotifierList *list);

    struct QEMUNotifierNode *
    qemu_notifier_list_add(QEMUNotifierList *list,
                           QEMUCallbackFunc notify, void *opaque);

    void qemu_notifier_list_remove(QEMUNotifierList *list,
                                   QEMUNotifierNode *notifier);

    void qemu_notifier_list_notify(QEMUNotifierList *list);

seems cleaner. You would place the QEMUNotifierNode in VncState in order to do the removal later.

I disagree. container_of() is both a little more type safe, and removes the need for an extra pointer and memory object.

The caller will almost always have an object in which to embed the notifier, best to make use of it.

error compiling committee.c: too many arguments to function

reply via email to

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