kobjects, sysfs and the driver model make my head hurt

[Matthew Wilcox <willy@debian.org>]

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