kobjects, sysfs and the driver model make my head hurt

Matthew Wilcox (willy@debian.org)
Sun, 6 Jul 2003 17:33:53 +0100


It's just all too complex. There's just too many levels of indirection
and structures which do almost the same thing and misleading functions.
It needs to be thoroughly simplified. Here's one particularly misleading
function:

/**
* kobject_get - increment refcount for object.
* @kobj: object.
*/

struct kobject * kobject_get(struct kobject * kobj)
{
struct kobject * ret = kobj;

if (kobj) {
WARN_ON(!atomic_read(&kobj->refcount));
atomic_inc(&kobj->refcount);
} else
ret = NULL;
return ret;
}

Why on earth does it return the value of its argument? And why's it
written in such a convoluted way? Here's a simpler form which retains
all the existing semantics:

struct kobject * kobject_get(struct kobject * kobj)
{
if (kobj) {
WARN_ON(!atomic_read(&kobj->refcount));
atomic_inc(&kobj->refcount);
}
return kobj;
}

or maybe better:

{
if (!kobj)
return NULL;
WARN_ON(!atomic_read(&kobj->refcount));
atomic_inc(&kobj->refcount);
return kobj;
}

But why return anything? Which looks clearer?

(a) kobj = kobject_get(kobj);

(b) kobject_get(kobj);

The first one makes me think that kobject_get might return a different
kobject than the one I passed in. That doesn't make much sense.

There's much more in this vein, but this email is long enough already.

<rmk> "you are in a maze of structures, all alike. There is a kset here."

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/