*must* a kset have an associated uevent_ops field?

["Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>]

  perusing kobject event code in lib/kobject_uevent.c and something
puzzles me.  early in kobject_uevent_env(), code guarantees that we
find an ancestor kobject that has a valid kset:

        /* search the kset we belong to */
        top_kobj = kobj;
        while (!top_kobj->kset && top_kobj->parent)
                top_kobj = top_kobj->parent;

        if (!top_kobj->kset) {
                pr_debug("kobject: '%s' (%p): %s: attempted to send uevent "
                         "without kset!\n", kobject_name(kobj), kobj,
                         __func__);
                return -EINVAL;
        }

        kset = top_kobj->kset;
        uevent_ops = kset->uevent_ops;

so, as i read it, at that point, we're *guaranteed* to have found the
closest kobject ancestor with a kset, and we save the relevant values
in "kset" and "uevent_ops".  so far, so good.

  but is there any guarantee that "uevent_ops" is non-null?  a little
below that, we read:

        if (uevent_ops && uevent_ops->filter)
                if (!uevent_ops->filter(kset, kobj)) {
                        pr_debug("kobject: '%s' (%p): %s: filter function "
                                 "caused the event to drop!\n",
                                 kobject_name(kobj), kobj, __func__);
                        return 0;
                }

which clearly first tests if "uevent_ops" is non-null.  so does that
mean it might be?

  and the same check occurs twice more in that routine:

        ...
        /* originating subsystem */
        if (uevent_ops && uevent_ops->name)
                subsystem = uevent_ops->name(kset, kobj);
        ...
        /* let the kset specific function add its stuff */
        if (uevent_ops && uevent_ops->uevent) {
        ...

  is it really necessary to keep making that test?  is there no way to
simplify the code so that that test is done early, and reduces the
subsequent code?  just curious.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies