kobject.txt 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367
  1. The kobject Infrastructure
  2. Patrick Mochel <mochel@osdl.org>
  3. Updated: 3 June 2003
  4. Copyright (c) 2003 Patrick Mochel
  5. Copyright (c) 2003 Open Source Development Labs
  6. 0. Introduction
  7. The kobject infrastructure performs basic object management that larger
  8. data structures and subsystems can leverage, rather than reimplement
  9. similar functionality. This functionality primarily concerns:
  10. - Object reference counting.
  11. - Maintaining lists (sets) of objects.
  12. - Object set locking.
  13. - Userspace representation.
  14. The infrastructure consists of a number of object types to support
  15. this functionality. Their programming interfaces are described below
  16. in detail, and briefly here:
  17. - kobjects a simple object.
  18. - kset a set of objects of a certain type.
  19. - ktype a set of helpers for objects of a common type.
  20. - subsystem a controlling object for a number of ksets.
  21. The kobject infrastructure maintains a close relationship with the
  22. sysfs filesystem. Each kobject that is registered with the kobject
  23. core receives a directory in sysfs. Attributes about the kobject can
  24. then be exported. Please see Documentation/filesystems/sysfs.txt for
  25. more information.
  26. The kobject infrastructure provides a flexible programming interface,
  27. and allows kobjects and ksets to be used without being registered
  28. (i.e. with no sysfs representation). This is also described later.
  29. 1. kobjects
  30. 1.1 Description
  31. struct kobject is a simple data type that provides a foundation for
  32. more complex object types. It provides a set of basic fields that
  33. almost all complex data types share. kobjects are intended to be
  34. embedded in larger data structures and replace fields they duplicate.
  35. 1.2 Definition
  36. struct kobject {
  37. char name[KOBJ_NAME_LEN];
  38. atomic_t refcount;
  39. struct list_head entry;
  40. struct kobject * parent;
  41. struct kset * kset;
  42. struct kobj_type * ktype;
  43. struct dentry * dentry;
  44. };
  45. void kobject_init(struct kobject *);
  46. int kobject_add(struct kobject *);
  47. int kobject_register(struct kobject *);
  48. void kobject_del(struct kobject *);
  49. void kobject_unregister(struct kobject *);
  50. struct kobject * kobject_get(struct kobject *);
  51. void kobject_put(struct kobject *);
  52. 1.3 kobject Programming Interface
  53. kobjects may be dynamically added and removed from the kobject core
  54. using kobject_register() and kobject_unregister(). Registration
  55. includes inserting the kobject in the list of its dominant kset and
  56. creating a directory for it in sysfs.
  57. Alternatively, one may use a kobject without adding it to its kset's list
  58. or exporting it via sysfs, by simply calling kobject_init(). An
  59. initialized kobject may later be added to the object hierarchy by
  60. calling kobject_add(). An initialized kobject may be used for
  61. reference counting.
  62. Note: calling kobject_init() then kobject_add() is functionally
  63. equivalent to calling kobject_register().
  64. When a kobject is unregistered, it is removed from its kset's list,
  65. removed from the sysfs filesystem, and its reference count is decremented.
  66. List and sysfs removal happen in kobject_del(), and may be called
  67. manually. kobject_put() decrements the reference count, and may also
  68. be called manually.
  69. A kobject's reference count may be incremented with kobject_get(),
  70. which returns a valid reference to a kobject; and decremented with
  71. kobject_put(). An object's reference count may only be incremented if
  72. it is already positive.
  73. When a kobject's reference count reaches 0, the method struct
  74. kobj_type::release() (which the kobject's kset points to) is called.
  75. This allows any memory allocated for the object to be freed.
  76. NOTE!!!
  77. It is _imperative_ that you supply a destructor for dynamically
  78. allocated kobjects to free them if you are using kobject reference
  79. counts. The reference count controls the lifetime of the object.
  80. If it goes to 0, then it is assumed that the object will
  81. be freed and cannot be used.
  82. More importantly, you must free the object there, and not immediately
  83. after an unregister call. If someone else is referencing the object
  84. (e.g. through a sysfs file), they will obtain a reference to the
  85. object, assume it's valid and operate on it. If the object is
  86. unregistered and freed in the meantime, the operation will then
  87. reference freed memory and go boom.
  88. This can be prevented, in the simplest case, by defining a release
  89. method and freeing the object from there only. Note that this will not
  90. secure reference count/object management models that use a dual
  91. reference count or do other wacky things with the reference count
  92. (like the networking layer).
  93. 1.4 sysfs
  94. Each kobject receives a directory in sysfs. This directory is created
  95. under the kobject's parent directory.
  96. If a kobject does not have a parent when it is registered, its parent
  97. becomes its dominant kset.
  98. If a kobject does not have a parent nor a dominant kset, its directory
  99. is created at the top-level of the sysfs partition. This should only
  100. happen for kobjects that are embedded in a struct subsystem.
  101. 2. ksets
  102. 2.1 Description
  103. A kset is a set of kobjects that are embedded in the same type.
  104. struct kset {
  105. struct subsystem * subsys;
  106. struct kobj_type * ktype;
  107. struct list_head list;
  108. struct kobject kobj;
  109. };
  110. void kset_init(struct kset * k);
  111. int kset_add(struct kset * k);
  112. int kset_register(struct kset * k);
  113. void kset_unregister(struct kset * k);
  114. struct kset * kset_get(struct kset * k);
  115. void kset_put(struct kset * k);
  116. struct kobject * kset_find_obj(struct kset *, char *);
  117. The type that the kobjects are embedded in is described by the ktype
  118. pointer. The subsystem that the kobject belongs to is pointed to by the
  119. subsys pointer.
  120. A kset contains a kobject itself, meaning that it may be registered in
  121. the kobject hierarchy and exported via sysfs. More importantly, the
  122. kset may be embedded in a larger data type, and may be part of another
  123. kset (of that object type).
  124. For example, a block device is an object (struct gendisk) that is
  125. contained in a set of block devices. It may also contain a set of
  126. partitions (struct hd_struct) that have been found on the device. The
  127. following code snippet illustrates how to express this properly.
  128. struct gendisk * disk;
  129. ...
  130. disk->kset.kobj.kset = &block_kset;
  131. disk->kset.ktype = &partition_ktype;
  132. kset_register(&disk->kset);
  133. - The kset that the disk's embedded object belongs to is the
  134. block_kset, and is pointed to by disk->kset.kobj.kset.
  135. - The type of objects on the disk's _subordinate_ list are partitions,
  136. and is set in disk->kset.ktype.
  137. - The kset is then registered, which handles initializing and adding
  138. the embedded kobject to the hierarchy.
  139. 2.2 kset Programming Interface
  140. All kset functions, except kset_find_obj(), eventually forward the
  141. calls to their embedded kobjects after performing kset-specific
  142. operations. ksets offer a similar programming model to kobjects: they
  143. may be used after they are initialized, without registering them in
  144. the hierarchy.
  145. kset_find_obj() may be used to locate a kobject with a particular
  146. name. The kobject, if found, is returned.
  147. 2.3 sysfs
  148. ksets are represented in sysfs when their embedded kobjects are
  149. registered. They follow the same rules of parenting, with one
  150. exception. If a kset does not have a parent, nor is its embedded
  151. kobject part of another kset, the kset's parent becomes its dominant
  152. subsystem.
  153. If the kset does not have a parent, its directory is created at the
  154. sysfs root. This should only happen when the kset registered is
  155. embedded in a subsystem itself.
  156. 3. struct ktype
  157. 3.1. Description
  158. struct kobj_type {
  159. void (*release)(struct kobject *);
  160. struct sysfs_ops * sysfs_ops;
  161. struct attribute ** default_attrs;
  162. };
  163. Object types require specific functions for converting between the
  164. generic object and the more complex type. struct kobj_type provides
  165. the object-specific fields, which include:
  166. - release: Called when the kobject's reference count reaches 0. This
  167. should convert the object to the more complex type and free it.
  168. - sysfs_ops: Provides conversion functions for sysfs access. Please
  169. see the sysfs documentation for more information.
  170. - default_attrs: Default attributes to be exported via sysfs when the
  171. object is registered.Note that the last attribute has to be
  172. initialized to NULL ! You can find a complete implementation
  173. in block/genhd.c
  174. Instances of struct kobj_type are not registered; only referenced by
  175. the kset. A kobj_type may be referenced by an arbitrary number of
  176. ksets, as there may be disparate sets of identical objects.
  177. 4. subsystems
  178. 4.1 Description
  179. A subsystem represents a significant entity of code that maintains an
  180. arbitrary number of sets of objects of various types. Since the number
  181. of ksets and the type of objects they contain are variable, a
  182. generic representation of a subsystem is minimal.
  183. struct subsystem {
  184. struct kset kset;
  185. struct rw_semaphore rwsem;
  186. };
  187. int subsystem_register(struct subsystem *);
  188. void subsystem_unregister(struct subsystem *);
  189. struct subsystem * subsys_get(struct subsystem * s);
  190. void subsys_put(struct subsystem * s);
  191. A subsystem contains an embedded kset so:
  192. - It can be represented in the object hierarchy via the kset's
  193. embedded kobject.
  194. - It can maintain a default list of objects of one type.
  195. Additional ksets may attach to the subsystem simply by referencing the
  196. subsystem before they are registered. (This one-way reference means
  197. that there is no way to determine the ksets that are attached to the
  198. subsystem.)
  199. All ksets that are attached to a subsystem share the subsystem's R/W
  200. semaphore.
  201. 4.2 subsystem Programming Interface.
  202. The subsystem programming interface is simple and does not offer the
  203. flexibility that the kset and kobject programming interfaces do. They
  204. may be registered and unregistered, as well as reference counted. Each
  205. call forwards the calls to their embedded ksets (which forward the
  206. calls to their embedded kobjects).
  207. 4.3 Helpers
  208. A number of macros are available to make dealing with subsystems and
  209. their embedded objects easier.
  210. decl_subsys(name,type)
  211. Declares a subsystem named '<name>_subsys', with an embedded kset of
  212. type <type>. For example,
  213. decl_subsys(devices,&ktype_devices);
  214. is equivalent to doing:
  215. struct subsystem device_subsys = {
  216. .kset = {
  217. .kobj = {
  218. .name = "devices",
  219. },
  220. .ktype = &ktype_devices,
  221. }
  222. };
  223. The objects that are registered with a subsystem that use the
  224. subsystem's default list must have their kset ptr set properly. These
  225. objects may have embedded kobjects, ksets, or other subsystems. The
  226. following helpers make setting the kset easier:
  227. kobj_set_kset_s(obj,subsys)
  228. - Assumes that obj->kobj exists, and is a struct kobject.
  229. - Sets the kset of that kobject to the subsystem's embedded kset.
  230. kset_set_kset_s(obj,subsys)
  231. - Assumes that obj->kset exists, and is a struct kset.
  232. - Sets the kset of the embedded kobject to the subsystem's
  233. embedded kset.
  234. subsys_set_kset(obj,subsys)
  235. - Assumes obj->subsys exists, and is a struct subsystem.
  236. - Sets obj->subsys.kset.kobj.kset to the subsystem's embedded kset.
  237. 4.4 sysfs
  238. subsystems are represented in sysfs via their embedded kobjects. They
  239. follow the same rules as previously mentioned with no exceptions. They
  240. typically receive a top-level directory in sysfs, except when their
  241. embedded kobject is part of another kset, or the parent of the
  242. embedded kobject is explicitly set.
  243. Note that the subsystem's embedded kset must be 'attached' to the
  244. subsystem itself in order to use its rwsem. This is done after
  245. kset_add() has been called. (Not before, because kset_add() uses its
  246. subsystem for a default parent if it doesn't already have one).