Lines Matching refs:to
1 Everything you never wanted to know about kobjects, ksets, and ktypes
14 all of which make reference to each other. In an attempt to make things
21 objects to be arranged into hierarchies), a specific type, and,
29 If it does, the reference counting for the object is sure to be messed
34 what happens to the kobject when it is created and destroyed.
37 or belong to different ktypes. The kset is the basic container type for
43 of those directories corresponds to a kobject in the same kset.
45 We'll look at how to create and manipulate all of these types. A bottom-up
46 approach will be taken, so we'll go back to kobjects.
51 It is rare for kernel code to create a standalone kobject, with one major
52 exception explained below. Instead, kobjects are used to control access to
54 embedded in other structures. If you are used to thinking of things in
58 nice to have in other objects. The C language does not allow for the
63 this is analogous as to how "list_head" structs are rarely useful on
78 what is the pointer to the containing structure? You must avoid tricks
86 * "pointer" is the pointer to the embedded kobject,
88 * "member" is the name of the structure field to which "pointer" points.
90 The return value from container_of() is a pointer to the corresponding
91 container type. So, for example, a pointer "kp" to a struct kobject
92 embedded *within* a struct uio_map could be converted to a pointer to the
98 kobject pointers to the containing type. Exactly this happens in the
108 where the macro argument "map" is a pointer to the struct kobject in
117 of the internal fields are setup with a (mandatory) call to kobject_init():
121 The ktype is required for a kobject to be created properly, as every kobject
122 must have an associated kobj_type. After calling kobject_init(), to
128 properly. If the kobject is to be associated with a specific kset,
130 associated with a kobject, then the parent for the kobject can be set to
131 NULL in the call to kobject_add() and then the kobject's parent will be the
134 As the name of the kobject is set when it is added to the kernel, the name
145 is being removed. If your code needs to call this function, it is
146 incorrect and needs to be fixed.
153 There is a helper function to both initialize and add the kobject to the
165 After a kobject has been registered with the kobject core, you need to
166 announce to the world that it has been created. This can be done with a
167 call to kobject_uevent():
171 Use the KOBJ_ADD action for when the kobject is first added to the kernel.
173 have been initialized properly, as userspace will instantly start to look
176 When the kobject is removed from the kernel (details on how to do that are
178 kobject core, so the caller does not have to worry about doing that by
184 One of the key functions of a kobject is to serve as a reference counter
185 for the object in which it is embedded. As long as references to the object
186 exist, the object (and the code which supports it) must continue to exist.
192 A successful call to kobject_get() will increment the kobject's reference
193 counter and return the pointer to the kobject.
195 When a reference is released, the call to kobject_put() will decrement the
197 sets the reference count to one, so the code which sets up the kobject will
198 need to do a kobject_put() eventually to release that reference.
205 If all that you want to use a kobject for is to provide a reference counter
207 overkill. For more information on how to use struct kref, please see the
213 Sometimes all that a developer wants is a way to create a simple directory
214 in the sysfs hierarchy, and not have to mess with the whole complication of
231 special custom attribute is needed to be created.
240 One important thing still missing from the discussion is what happens to a
249 before its reference count goes to zero. The reference count is not under
251 be notified asynchronously whenever the last reference to one of its
255 kfree() to free it directly. The only safe way is to use kobject_put(). It
256 is good practice to always use kobject_put() after kobject_init() to avoid
273 flawed. Note that the kernel will warn you if you forget to provide a
274 release() method. Do not try to get rid of this warning by providing an
294 This structure is used to describe a particular type of kobject (or, more
295 correctly, of containing object). Every kobject needs to have an associated
296 kobj_type structure; a pointer to that structure must be specified when you
299 The release field in struct kobj_type is, of course, a pointer to the
310 A kset is merely a collection of kobjects that want to be associated with
317 the kernel to track "all block devices" or "all PCI device drivers."
321 set up to be the parent of other kobjects; the top-level directories of
325 uevent events are reported to user space.
332 back to their containing kset via their kset field. In almost all cases,
333 the kobjects belonging to a kset have that kset (or, strictly, its embedded
345 to destroy it. This removes the kset from sysfs and decrements its reference
346 count. When the reference count goes to zero, the kset will be released.
347 Because other references to the kset may still exist, the release may happen
353 If a kset wishes to control the uevent operations of the kobjects
354 associated with it, it can use the struct kset_uevent_ops to handle it:
364 The filter function allows a kset to prevent a uevent from being emitted to
368 The name function will be called to override the default name of the kset
369 that the uevent sends to userspace. By default, the name will be the same
372 The uevent function will be called when the uevent is about to be sent to
373 userspace to allow more environment variables to be added to the uevent.
375 One might ask how, exactly, a kobject is added to a kset, given that no
377 that this task is handled by kobject_add(). When a kobject is passed to
378 kobject_add(), its kset member should point to the kset to which the
381 If the kobject belonging to a kset has no parent kobject set, it will be
382 added to the kset's directory. Not all members of a kset do necessarily
397 If you need to do a two-stage delete of the kobject (say you are not
398 allowed to sleep when you need to destroy the object), then call
401 the object is still the same. At a later time call kobject_put() to finish
404 kobject_del() can be used to drop the reference to the parent object, if
407 with an explicit call to kobject_del(), so that a release functions will be
411 Example code to copy from