diff options
Diffstat (limited to 'Documentation/kobject.txt')
| -rw-r--r-- | Documentation/kobject.txt | 434 |
1 files changed, 0 insertions, 434 deletions
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt deleted file mode 100644 index ff4c25098119..000000000000 --- a/Documentation/kobject.txt +++ /dev/null @@ -1,434 +0,0 @@ -===================================================================== -Everything you never wanted to know about kobjects, ksets, and ktypes -===================================================================== - -:Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -:Last updated: December 19, 2007 - -Based on an original article by Jon Corbet for lwn.net written October 1, -2003 and located at http://lwn.net/Articles/51437/ - -Part of the difficulty in understanding the driver model - and the kobject -abstraction upon which it is built - is that there is no obvious starting -place. Dealing with kobjects requires understanding a few different types, -all of which make reference to each other. In an attempt to make things -easier, we'll take a multi-pass approach, starting with vague terms and -adding detail as we go. To that end, here are some quick definitions of -some terms we will be working with. - - - A kobject is an object of type struct kobject. Kobjects have a name - and a reference count. A kobject also has a parent pointer (allowing - objects to be arranged into hierarchies), a specific type, and, - usually, a representation in the sysfs virtual filesystem. - - Kobjects are generally not interesting on their own; instead, they are - usually embedded within some other structure which contains the stuff - the code is really interested in. - - No structure should EVER have more than one kobject embedded within it. - If it does, the reference counting for the object is sure to be messed - up and incorrect, and your code will be buggy. So do not do this. - - - A ktype is the type of object that embeds a kobject. Every structure - that embeds a kobject needs a corresponding ktype. The ktype controls - what happens to the kobject when it is created and destroyed. - - - A kset is a group of kobjects. These kobjects can be of the same ktype - or belong to different ktypes. The kset is the basic container type for - collections of kobjects. Ksets contain their own kobjects, but you can - safely ignore that implementation detail as the kset core code handles - this kobject automatically. - - When you see a sysfs directory full of other directories, generally each - of those directories corresponds to a kobject in the same kset. - -We'll look at how to create and manipulate all of these types. A bottom-up -approach will be taken, so we'll go back to kobjects. - - -Embedding kobjects -================== - -It is rare for kernel code to create a standalone kobject, with one major -exception explained below. Instead, kobjects are used to control access to -a larger, domain-specific object. To this end, kobjects will be found -embedded in other structures. If you are used to thinking of things in -object-oriented terms, kobjects can be seen as a top-level, abstract class -from which other classes are derived. A kobject implements a set of -capabilities which are not particularly useful by themselves, but which are -nice to have in other objects. The C language does not allow for the -direct expression of inheritance, so other techniques - such as structure -embedding - must be used. - -(As an aside, for those familiar with the kernel linked list implementation, -this is analogous as to how "list_head" structs are rarely useful on -their own, but are invariably found embedded in the larger objects of -interest.) - -So, for example, the UIO code in drivers/uio/uio.c has a structure that -defines the memory region associated with a uio device:: - - struct uio_map { - struct kobject kobj; - struct uio_mem *mem; - }; - -If you have a struct uio_map structure, finding its embedded kobject is -just a matter of using the kobj member. Code that works with kobjects will -often have the opposite problem, however: given a struct kobject pointer, -what is the pointer to the containing structure? You must avoid tricks -(such as assuming that the kobject is at the beginning of the structure) -and, instead, use the container_of() macro, found in <linux/kernel.h>:: - - container_of(pointer, type, member) - -where: - - * "pointer" is the pointer to the embedded kobject, - * "type" is the type of the containing structure, and - * "member" is the name of the structure field to which "pointer" points. - -The return value from container_of() is a pointer to the corresponding -container type. So, for example, a pointer "kp" to a struct kobject -embedded *within* a struct uio_map could be converted to a pointer to the -*containing* uio_map structure with:: - - struct uio_map *u_map = container_of(kp, struct uio_map, kobj); - -For convenience, programmers often define a simple macro for "back-casting" -kobject pointers to the containing type. Exactly this happens in the -earlier drivers/uio/uio.c, as you can see here:: - - struct uio_map { - struct kobject kobj; - struct uio_mem *mem; - }; - - #define to_map(map) container_of(map, struct uio_map, kobj) - -where the macro argument "map" is a pointer to the struct kobject in -question. That macro is subsequently invoked with:: - - struct uio_map *map = to_map(kobj); - - -Initialization of kobjects -========================== - -Code which creates a kobject must, of course, initialize that object. Some -of the internal fields are setup with a (mandatory) call to kobject_init():: - - void kobject_init(struct kobject *kobj, struct kobj_type *ktype); - -The ktype is required for a kobject to be created properly, as every kobject -must have an associated kobj_type. After calling kobject_init(), to -register the kobject with sysfs, the function kobject_add() must be called:: - - int kobject_add(struct kobject *kobj, struct kobject *parent, - const char *fmt, ...); - -This sets up the parent of the kobject and the name for the kobject -properly. If the kobject is to be associated with a specific kset, -kobj->kset must be assigned before calling kobject_add(). If a kset is -associated with a kobject, then the parent for the kobject can be set to -NULL in the call to kobject_add() and then the kobject's parent will be the -kset itself. - -As the name of the kobject is set when it is added to the kernel, the name -of the kobject should never be manipulated directly. If you must change -the name of the kobject, call kobject_rename():: - - int kobject_rename(struct kobject *kobj, const char *new_name); - -kobject_rename does not perform any locking or have a solid notion of -what names are valid so the caller must provide their own sanity checking -and serialization. - -There is a function called kobject_set_name() but that is legacy cruft and -is being removed. If your code needs to call this function, it is -incorrect and needs to be fixed. - -To properly access the name of the kobject, use the function -kobject_name():: - - const char *kobject_name(const struct kobject * kobj); - -There is a helper function to both initialize and add the kobject to the -kernel at the same time, called surprisingly enough kobject_init_and_add():: - - int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype, - struct kobject *parent, const char *fmt, ...); - -The arguments are the same as the individual kobject_init() and -kobject_add() functions described above. - - -Uevents -======= - -After a kobject has been registered with the kobject core, you need to -announce to the world that it has been created. This can be done with a -call to kobject_uevent():: - - int kobject_uevent(struct kobject *kobj, enum kobject_action action); - -Use the KOBJ_ADD action for when the kobject is first added to the kernel. -This should be done only after any attributes or children of the kobject -have been initialized properly, as userspace will instantly start to look -for them when this call happens. - -When the kobject is removed from the kernel (details on how to do that are -below), the uevent for KOBJ_REMOVE will be automatically created by the -kobject core, so the caller does not have to worry about doing that by -hand. - - -Reference counts -================ - -One of the key functions of a kobject is to serve as a reference counter -for the object in which it is embedded. As long as references to the object -exist, the object (and the code which supports it) must continue to exist. -The low-level functions for manipulating a kobject's reference counts are:: - - struct kobject *kobject_get(struct kobject *kobj); - void kobject_put(struct kobject *kobj); - -A successful call to kobject_get() will increment the kobject's reference -counter and return the pointer to the kobject. - -When a reference is released, the call to kobject_put() will decrement the -reference count and, possibly, free the object. Note that kobject_init() -sets the reference count to one, so the code which sets up the kobject will -need to do a kobject_put() eventually to release that reference. - -Because kobjects are dynamic, they must not be declared statically or on -the stack, but instead, always allocated dynamically. Future versions of -the kernel will contain a run-time check for kobjects that are created -statically and will warn the developer of this improper usage. - -If all that you want to use a kobject for is to provide a reference counter -for your structure, please use the struct kref instead; a kobject would be -overkill. For more information on how to use struct kref, please see the -file Documentation/kref.txt in the Linux kernel source tree. - - -Creating "simple" kobjects -========================== - -Sometimes all that a developer wants is a way to create a simple directory -in the sysfs hierarchy, and not have to mess with the whole complication of -ksets, show and store functions, and other details. This is the one -exception where a single kobject should be created. To create such an -entry, use the function:: - - struct kobject *kobject_create_and_add(char *name, struct kobject *parent); - -This function will create a kobject and place it in sysfs in the location -underneath the specified parent kobject. To create simple attributes -associated with this kobject, use:: - - int sysfs_create_file(struct kobject *kobj, struct attribute *attr); - -or:: - - int sysfs_create_group(struct kobject *kobj, struct attribute_group *grp); - -Both types of attributes used here, with a kobject that has been created -with the kobject_create_and_add(), can be of type kobj_attribute, so no -special custom attribute is needed to be created. - -See the example module, samples/kobject/kobject-example.c for an -implementation of a simple kobject and attributes. - - - -ktypes and release methods -========================== - -One important thing still missing from the discussion is what happens to a -kobject when its reference count reaches zero. The code which created the -kobject generally does not know when that will happen; if it did, there -would be little point in using a kobject in the first place. Even -predictable object lifecycles become more complicated when sysfs is brought -in as other portions of the kernel can get a reference on any kobject that -is registered in the system. - -The end result is that a structure protected by a kobject cannot be freed -before its reference count goes to zero. The reference count is not under -the direct control of the code which created the kobject. So that code must -be notified asynchronously whenever the last reference to one of its -kobjects goes away. - -Once you registered your kobject via kobject_add(), you must never use -kfree() to free it directly. The only safe way is to use kobject_put(). It -is good practice to always use kobject_put() after kobject_init() to avoid -errors creeping in. - -This notification is done through a kobject's release() method. Usually -such a method has a form like:: - - void my_object_release(struct kobject *kobj) - { - struct my_object *mine = container_of(kobj, struct my_object, kobj); - - /* Perform any additional cleanup on this object, then... */ - kfree(mine); - } - -One important point cannot be overstated: every kobject must have a -release() method, and the kobject must persist (in a consistent state) -until that method is called. If these constraints are not met, the code is -flawed. Note that the kernel will warn you if you forget to provide a -release() method. Do not try to get rid of this warning by providing an -"empty" release function. - -If all your cleanup function needs to do is call kfree(), then you must -create a wrapper function which uses container_of() to upcast to the correct -type (as shown in the example above) and then calls kfree() on the overall -structure. - -Note, the name of the kobject is available in the release function, but it -must NOT be changed within this callback. Otherwise there will be a memory -leak in the kobject core, which makes people unhappy. - -Interestingly, the release() method is not stored in the kobject itself; -instead, it is associated with the ktype. So let us introduce struct -kobj_type:: - - struct kobj_type { - void (*release)(struct kobject *kobj); - const struct sysfs_ops *sysfs_ops; - struct attribute **default_attrs; - const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); - const void *(*namespace)(struct kobject *kobj); - }; - -This structure is used to describe a particular type of kobject (or, more -correctly, of containing object). Every kobject needs to have an associated -kobj_type structure; a pointer to that structure must be specified when you -call kobject_init() or kobject_init_and_add(). - -The release field in struct kobj_type is, of course, a pointer to the -release() method for this type of kobject. The other two fields (sysfs_ops -and default_attrs) control how objects of this type are represented in -sysfs; they are beyond the scope of this document. - -The default_attrs pointer is a list of default attributes that will be -automatically created for any kobject that is registered with this ktype. - - -ksets -===== - -A kset is merely a collection of kobjects that want to be associated with -each other. There is no restriction that they be of the same ktype, but be -very careful if they are not. - -A kset serves these functions: - - - It serves as a bag containing a group of objects. A kset can be used by - the kernel to track "all block devices" or "all PCI device drivers." - - - A kset is also a subdirectory in sysfs, where the associated kobjects - with the kset can show up. Every kset contains a kobject which can be - set up to be the parent of other kobjects; the top-level directories of - the sysfs hierarchy are constructed in this way. - - - Ksets can support the "hotplugging" of kobjects and influence how - uevent events are reported to user space. - -In object-oriented terms, "kset" is the top-level container class; ksets -contain their own kobject, but that kobject is managed by the kset code and -should not be manipulated by any other user. - -A kset keeps its children in a standard kernel linked list. Kobjects point -back to their containing kset via their kset field. In almost all cases, -the kobjects belonging to a kset have that kset (or, strictly, its embedded -kobject) in their parent. - -As a kset contains a kobject within it, it should always be dynamically -created and never declared statically or on the stack. To create a new -kset use:: - - struct kset *kset_create_and_add(const char *name, - struct kset_uevent_ops *u, - struct kobject *parent); - -When you are finished with the kset, call:: - - void kset_unregister(struct kset *kset); - -to destroy it. This removes the kset from sysfs and decrements its reference -count. When the reference count goes to zero, the kset will be released. -Because other references to the kset may still exist, the release may happen -after kset_unregister() returns. - -An example of using a kset can be seen in the -samples/kobject/kset-example.c file in the kernel tree. - -If a kset wishes to control the uevent operations of the kobjects -associated with it, it can use the struct kset_uevent_ops to handle it:: - - struct kset_uevent_ops { - int (*filter)(struct kset *kset, struct kobject *kobj); - const char *(*name)(struct kset *kset, struct kobject *kobj); - int (*uevent)(struct kset *kset, struct kobject *kobj, - struct kobj_uevent_env *env); - }; - - -The filter function allows a kset to prevent a uevent from being emitted to -userspace for a specific kobject. If the function returns 0, the uevent -will not be emitted. - -The name function will be called to override the default name of the kset -that the uevent sends to userspace. By default, the name will be the same -as the kset itself, but this function, if present, can override that name. - -The uevent function will be called when the uevent is about to be sent to -userspace to allow more environment variables to be added to the uevent. - -One might ask how, exactly, a kobject is added to a kset, given that no -functions which perform that function have been presented. The answer is -that this task is handled by kobject_add(). When a kobject is passed to -kobject_add(), its kset member should point to the kset to which the -kobject will belong. kobject_add() will handle the rest. - -If the kobject belonging to a kset has no parent kobject set, it will be -added to the kset's directory. Not all members of a kset do necessarily -live in the kset directory. If an explicit parent kobject is assigned -before the kobject is added, the kobject is registered with the kset, but -added below the parent kobject. - - -Kobject removal -=============== - -After a kobject has been registered with the kobject core successfully, it -must be cleaned up when the code is finished with it. To do that, call -kobject_put(). By doing this, the kobject core will automatically clean up -all of the memory allocated by this kobject. If a KOBJ_ADD uevent has been -sent for the object, a corresponding KOBJ_REMOVE uevent will be sent, and -any other sysfs housekeeping will be handled for the caller properly. - -If you need to do a two-stage delete of the kobject (say you are not -allowed to sleep when you need to destroy the object), then call -kobject_del() which will unregister the kobject from sysfs. This makes the -kobject "invisible", but it is not cleaned up, and the reference count of -the object is still the same. At a later time call kobject_put() to finish -the cleanup of the memory associated with the kobject. - -kobject_del() can be used to drop the reference to the parent object, if -circular references are constructed. It is valid in some cases, that a -parent objects references a child. Circular references _must_ be broken -with an explicit call to kobject_del(), so that a release functions will be -called, and the objects in the former circle release each other. - - -Example code to copy from -========================= - -For a more complete example of using ksets and kobjects properly, see the -example programs samples/kobject/{kobject-example.c,kset-example.c}, -which will be built as loadable modules if you select CONFIG_SAMPLE_KOBJECT. |