kobjects - Simple, Generic Kernel Objects

Patrick Mochel <mochel@osdl.org>

30 October 2002


kobjects

struct kobject introduces a simple, intregral datatype and a simple
set of semantics for operating on the device. kobjects are intended to
be embedded in larger data structures and replace fields it
duplicates. A set of library functions has been developed to assist in
the manipulation of kobjects.

struct kobject looks like this:


struct kobject {
	char			name[16];
	atomic_t		refcount;
	struct list_head	entry;
	struct kobject		* parent;
	struct subsystem	* subsys;
	struct dentry		* dentry;
};

void kobject_init(struct kobject *);
int kobject_register(struct kobject *);
void kobject_unregister(struct kobject *);
struct kobject * kobject_get(struct kobject *);
void kobject_put(struct kobject *);



subsystems

struct subsystem is introduced to describe a collection of objects of
a certain type. subsystems are kobjects themselves, though they
contain lists of kobjects that belong to that subsystem. Objects of a
subsystem (the embedder objects in which kobjects live) are all of the
same type. The interface looks like:


struct subsystem {
	struct kobject		kobj;
	struct list_head	list;
	struct rw_semaphore	rwsem;
	struct subsystem	* parent;
	void (*release)(struct kobject *);
	struct sysfs_ops	* sysfs_ops;
	struct attribute	** default_attrs;
};

void subsystem_init(struct subsystem *);
int subsystem_register(struct subsystem *);
void subsystem_unregister(struct subsystem *);

struct subsystem * subsys_get(struct subsystem * s);
void subsys_put(struct subsystem * s);



Familial Relations

kobjects and subsystems intersect and intertwine in several ways. Each
is well-defined (though maybe they could be made simpler). Each kobject
belongs to a subsystem. Since subsystems are kobjects themselves, they
also belong to a controlling subsystem. This implies that subsystems
are hierarchial. 

Many kobjects are hierarchial in nature, which is represented by
including a pointer to its parent kobject in struct kobject. Many
different types of kobject-embedding objects may all point to the same
parent. 

The ancestral hierarchy of kobjects should not be confused with
membership in a subsystem, or the ancestral relationship of
subsystems. A set of kobjects may all belong to a subsystem, but all
have different parents. 

kobjects may be orphans and have no explicit parent. In that case, the
subsystem to which the object belongs becomes its parent. 


Sysfs

These rules force a complete kobject hierarchy, which Suprise! maps
very well onto a filesystem.

driverfs was recently cloned, and there now exists sysfs. All driverfs
operations operate on a separate data type: struct driver_dir_entry,
which all objects that are represented in driverfs must have. driverfs
also allowed rogue directory creation that had no explicit objects
associated with them.

struct kobject is intended to be the common data type which sysfs
operates on. This gives the filesystem the ability to directly access
more fields of the object, including the reference count. This also
forces each directory in the filesystem to be tied directly to a
kobject. 


Directory Placement

Parental relationships are determined in the kobject/subsystem layer,
and the kobject is then passed off to the sysfs layer. kobjects with
no parent have directories created for them in the sysfs root
directory. Per the rules above, the only kobjects that remain orphans
are subsystems without parent subsystems (since leaf objects either
have an explicit parent, or are assigned their controlling subsystem
as their foster parent). 


File Callbacks

Previously, each driverfs directory contained a pointer to a list of file
operations for reading and writing driverfs files. These callbacks
received a struct driver_dir_entry, when they performed a
container_of() transform on to receive the specific object type for
which the call was meant. 

These callbacks have been converted to accept a struct kobject instead
of struct driver_dir_entry. Since all kobjects belong to a subsystem
that contains kobjects all of the same type, the sysfs operations
have been moved to reside in the subsystem, since they are common for
all kobjects.


Default Attributes

Most subsystems have a set of default attributes associated with an
object that registers with them. A subsystem definition may contain a
NULL-terminated array of attributes that will be exported when an
object is registered with the subsystem. 


Reference Counting

All objects contain reference counts. All functions accessing objects
should increment the reference count until they are finished, and
decrement the reference count. When an object is initialized, it
receives a reference count of 1. When a device is unregistered, the
reference is decremented. When the reference counts reaches 0, the
subsystem's ->release() callback for that object type (remember
subsystems control only one type of device each) is called; and the
reference counts of the kobject's subsystem and parent are
decremented. 

The ->release() callback is the opportunity for the subsystem to free
memory allocated for the object. It is the notification that
absolutely no one is using the structure any more (and can't acquire a
reference to it), so it is safe to free it.

