Subversion Repositories or1k_soc_on_altera_embedded_dev_kit

The kobject Infrastructure

Patrick Mochel 

Updated: 3 June 2003

Copyright (c)  2003 Patrick Mochel

Copyright (c)  2003 Open Source Development Labs

0. Introduction

The kobject infrastructure performs basic object management that larger

data structures and subsystems can leverage, rather than reimplement

similar functionality. This functionality primarily concerns:

- Object reference counting.

- Maintaining lists (sets) of objects.

- Object set locking.

- Userspace representation.

The infrastructure consists of a number of object types to support

this functionality. Their programming interfaces are described below

in detail, and briefly here:

- kobjects      a simple object.

- kset          a set of objects of a certain type.

- ktype         a set of helpers for objects of a common type.

The kobject infrastructure maintains a close relationship with the

sysfs filesystem. Each kobject that is registered with the kobject

core receives a directory in sysfs. Attributes about the kobject can

then be exported. Please see Documentation/filesystems/sysfs.txt for

more information.

The kobject infrastructure provides a flexible programming interface,

and allows kobjects and ksets to be used without being registered

(i.e. with no sysfs representation). This is also described later.

1. kobjects

1.1 Description

struct kobject is a simple data type that provides a foundation for

more complex object types. It provides a set of basic fields that

almost all complex data types share. kobjects are intended to be

embedded in larger data structures and replace fields they duplicate.

1.2 Definition

struct kobject {

        const char              * k_name;

        struct kref             kref;

        struct list_head        entry;

        struct kobject          * parent;

        struct kset             * kset;

        struct kobj_type        * ktype;

        struct sysfs_dirent     * sd;

        wait_queue_head_t       poll;

};

void kobject_init(struct kobject *);

int kobject_add(struct kobject *);

int kobject_register(struct kobject *);

void kobject_del(struct kobject *);

void kobject_unregister(struct kobject *);

struct kobject * kobject_get(struct kobject *);

void kobject_put(struct kobject *);

1.3 kobject Programming Interface

kobjects may be dynamically added and removed from the kobject core

using kobject_register() and kobject_unregister(). Registration

includes inserting the kobject in the list of its dominant kset and

creating a directory for it in sysfs.

Alternatively, one may use a kobject without adding it to its kset's list

or exporting it via sysfs, by simply calling kobject_init(). An

initialized kobject may later be added to the object hierarchy by

calling kobject_add(). An initialized kobject may be used for

reference counting.

Note: calling kobject_init() then kobject_add() is functionally

equivalent to calling kobject_register().

When a kobject is unregistered, it is removed from its kset's list,

removed from the sysfs filesystem, and its reference count is decremented.

List and sysfs removal happen in kobject_del(), and may be called

manually. kobject_put() decrements the reference count, and may also

be called manually.

A kobject's reference count may be incremented with kobject_get(),

which returns a valid reference to a kobject; and decremented with

kobject_put(). An object's reference count may only be incremented if

it is already positive.

When a kobject's reference count reaches 0, the method struct

kobj_type::release() (which the kobject's kset points to) is called.

This allows any memory allocated for the object to be freed.

NOTE!!!

It is _imperative_ that you supply a destructor for dynamically

allocated kobjects to free them if you are using kobject reference

counts. The reference count controls the lifetime of the object.

If it goes to 0, then it is assumed that the object will

be freed and cannot be used.

More importantly, you must free the object there, and not immediately

after an unregister call. If someone else is referencing the object

(e.g. through a sysfs file), they will obtain a reference to the

object, assume it's valid and operate on it. If the object is

unregistered and freed in the meantime, the operation will then

reference freed memory and go boom.

This can be prevented, in the simplest case, by defining a release

method and freeing the object from there only. Note that this will not

secure reference count/object management models that use a dual

reference count or do other wacky things with the reference count

(like the networking layer).

1.4 sysfs

Each kobject receives a directory in sysfs. This directory is created

under the kobject's parent directory.

If a kobject does not have a parent when it is registered, its parent

becomes its dominant kset.

If a kobject does not have a parent nor a dominant kset, its directory

is created at the top-level of the sysfs partition.

2. ksets

2.1 Description

A kset is a set of kobjects that are embedded in the same type.

struct kset {

        struct kobj_type        * ktype;

        struct list_head        list;

        struct kobject          kobj;

        struct kset_uevent_ops  * uevent_ops;

};

void kset_init(struct kset * k);

int kset_add(struct kset * k);

int kset_register(struct kset * k);

void kset_unregister(struct kset * k);

struct kset * kset_get(struct kset * k);

void kset_put(struct kset * k);

struct kobject * kset_find_obj(struct kset *, char *);

The type that the kobjects are embedded in is described by the ktype

pointer.

A kset contains a kobject itself, meaning that it may be registered in

the kobject hierarchy and exported via sysfs. More importantly, the

kset may be embedded in a larger data type, and may be part of another

kset (of that object type).

For example, a block device is an object (struct gendisk) that is

contained in a set of block devices. It may also contain a set of

partitions (struct hd_struct) that have been found on the device. The

following code snippet illustrates how to express this properly.

         struct gendisk * disk;

         ...

         disk->kset.kobj.kset = &block_kset;

         disk->kset.ktype = &partition_ktype;

         kset_register(&disk->kset);

- The kset that the disk's embedded object belongs to is the

  block_kset, and is pointed to by disk->kset.kobj.kset.

- The type of objects on the disk's _subordinate_ list are partitions,

  and is set in disk->kset.ktype.

- The kset is then registered, which handles initializing and adding

  the embedded kobject to the hierarchy.

2.2 kset Programming Interface

All kset functions, except kset_find_obj(), eventually forward the

calls to their embedded kobjects after performing kset-specific

operations. ksets offer a similar programming model to kobjects: they

may be used after they are initialized, without registering them in

the hierarchy.

kset_find_obj() may be used to locate a kobject with a particular

name. The kobject, if found, is returned.

There are also some helper functions which names point to the formerly

existing "struct subsystem", whose functions have been taken over by

ksets.

decl_subsys(name,type,uevent_ops)

Declares a kset named '_subsys' of type  with

uevent_ops . For example,

decl_subsys(devices, &ktype_device, &device_uevent_ops);

is equivalent to doing:

struct kset devices_subsys = {

     .ktype = &ktype_devices,

     .uevent_ops = &device_uevent_ops,

};

kobject_set_name(&devices_subsys, name);

The objects that are registered with a subsystem that use the

subsystem's default list must have their kset ptr set properly. These

objects may have embedded kobjects or ksets. The

following helper makes setting the kset easier:

kobj_set_kset_s(obj,subsys)

- Assumes that obj->kobj exists, and is a struct kobject.

- Sets the kset of that kobject to the kset .

int subsystem_register(struct kset *s);

void subsystem_unregister(struct kset *s);

These are just wrappers around the respective kset_* functions.

2.3 sysfs

ksets are represented in sysfs when their embedded kobjects are

registered. They follow the same rules of parenting, with one

exception. If a kset does not have a parent, nor is its embedded

kobject part of another kset, the kset's parent becomes its dominant

subsystem.

If the kset does not have a parent, its directory is created at the

sysfs root. This should only happen when the kset registered is

embedded in a subsystem itself.

3. struct ktype

3.1. Description

struct kobj_type {

        void (*release)(struct kobject *);

        struct sysfs_ops        * sysfs_ops;

        struct attribute        ** default_attrs;

};

Object types require specific functions for converting between the

generic object and the more complex type. struct kobj_type provides

the object-specific fields, which include:

- release: Called when the kobject's reference count reaches 0. This

  should convert the object to the more complex type and free it.

- sysfs_ops: Provides conversion functions for sysfs access. Please

  see the sysfs documentation for more information.

- default_attrs: Default attributes to be exported via sysfs when the

  object is registered.Note that the last attribute has to be

  initialized to NULL ! You can find a complete implementation

  in block/genhd.c

Instances of struct kobj_type are not registered; only referenced by

the kset. A kobj_type may be referenced by an arbitrary number of

ksets, as there may be disparate sets of identical objects.