Lines Matching refs:kobject
11 Part of the difficulty in understanding the driver model - and the kobject
19 - A kobject is an object of type struct kobject. Kobjects have a name
20 and a reference count. A kobject also has a parent pointer (allowing
28 No structure should EVER have more than one kobject embedded within it.
32 - A ktype is the type of object that embeds a kobject. Every structure
33 that embeds a kobject needs a corresponding ktype. The ktype controls
34 what happens to the kobject when it is created and destroyed.
40 this kobject automatically.
43 of those directories corresponds to a kobject in the same kset.
51 It is rare for kernel code to create a standalone kobject, with one major
56 from which other classes are derived. A kobject implements a set of
71 struct kobject kobj;
75 If you have a struct uio_map structure, finding its embedded kobject is
77 often have the opposite problem, however: given a struct kobject pointer,
79 (such as assuming that the kobject is at the beginning of the structure)
86 * "pointer" is the pointer to the embedded kobject,
91 container type. So, for example, a pointer "kp" to a struct kobject
98 kobject pointers to the containing type. Exactly this happens in the
102 struct kobject kobj;
108 where the macro argument "map" is a pointer to the struct kobject in
116 Code which creates a kobject must, of course, initialize that object. Some
119 void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
121 The ktype is required for a kobject to be created properly, as every kobject
123 register the kobject with sysfs, the function kobject_add() must be called:
125 int kobject_add(struct kobject *kobj, struct kobject *parent, const char *fmt, ...);
127 This sets up the parent of the kobject and the name for the kobject
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
135 of the kobject should never be manipulated directly. If you must change
136 the name of the kobject, call kobject_rename():
138 int kobject_rename(struct kobject *kobj, const char *new_name);
148 To properly access the name of the kobject, use the function
151 const char *kobject_name(const struct kobject * kobj);
153 There is a helper function to both initialize and add the kobject to the
156 int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
157 struct kobject *parent, const char *fmt, ...);
165 After a kobject has been registered with the kobject core, you need to
169 int kobject_uevent(struct kobject *kobj, enum kobject_action action);
171 Use the KOBJ_ADD action for when the kobject is first added to the kernel.
172 This should be done only after any attributes or children of the kobject
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
187 The low-level functions for manipulating a kobject's reference counts are:
189 struct kobject *kobject_get(struct kobject *kobj);
190 void kobject_put(struct kobject *kobj);
192 A successful call to kobject_get() will increment the kobject's reference
193 counter and return the pointer to the kobject.
197 sets the reference count to one, so the code which sets up the kobject will
205 If all that you want to use a kobject for is to provide a reference counter
206 for your structure, please use the struct kref instead; a kobject would be
216 exception where a single kobject should be created. To create such an
219 struct kobject *kobject_create_and_add(char *name, struct kobject *parent);
221 This function will create a kobject and place it in sysfs in the location
222 underneath the specified parent kobject. To create simple attributes
223 associated with this kobject, use:
225 int sysfs_create_file(struct kobject *kobj, struct attribute *attr);
227 int sysfs_create_group(struct kobject *kobj, struct attribute_group *grp);
229 Both types of attributes used here, with a kobject that has been created
233 See the example module, samples/kobject/kobject-example.c for an
234 implementation of a simple kobject and attributes.
241 kobject when its reference count reaches zero. The code which created the
242 kobject generally does not know when that will happen; if it did, there
243 would be little point in using a kobject in the first place. Even
245 in as other portions of the kernel can get a reference on any kobject that
248 The end result is that a structure protected by a kobject cannot be freed
250 the direct control of the code which created the kobject. So that code must
254 Once you registered your kobject via kobject_add(), you must never use
259 This notification is done through a kobject's release() method. Usually
262 void my_object_release(struct kobject *kobj)
270 One important point cannot be overstated: every kobject must have a
271 release() method, and the kobject must persist (in a consistent state)
275 "empty" release function; you will be mocked mercilessly by the kobject
278 Note, the name of the kobject is available in the release function, but it
280 leak in the kobject core, which makes people unhappy.
282 Interestingly, the release() method is not stored in the kobject itself;
287 void (*release)(struct kobject *kobj);
290 const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
291 const void *(*namespace)(struct kobject *kobj);
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
300 release() method for this type of kobject. The other two fields (sysfs_ops
305 automatically created for any kobject that is registered with this ktype.
320 with the kset can show up. Every kset contains a kobject which can be
328 contain their own kobject, but that kobject is managed by the kset code and
334 kobject) in their parent.
336 As a kset contains a kobject within it, it should always be dynamically
341 struct kobject *parent);
351 samples/kobject/kset-example.c file in the kernel tree.
357 int (*filter)(struct kset *kset, struct kobject *kobj);
358 const char *(*name)(struct kset *kset, struct kobject *kobj);
359 int (*uevent)(struct kset *kset, struct kobject *kobj,
365 userspace for a specific kobject. If the function returns 0, 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
379 kobject will belong. kobject_add() will handle the rest.
381 If the kobject belonging to a kset has no parent kobject set, it will be
383 live in the kset directory. If an explicit parent kobject is assigned
384 before the kobject is added, the kobject is registered with the kset, but
385 added below the parent kobject.
390 After a kobject has been registered with the kobject core successfully, it
392 kobject_put(). By doing this, the kobject core will automatically clean up
393 all of the memory allocated by this kobject. If a KOBJ_ADD uevent has been
397 If you need to do a two-stage delete of the kobject (say you are not
399 kobject_del() which will unregister the kobject from sysfs. This makes the
400 kobject "invisible", but it is not cleaned up, and the reference count of
402 the cleanup of the memory associated with the kobject.
414 example programs samples/kobject/{kobject-example.c,kset-example.c},