kobject_add(9)

💅 NAME 💅

kobject_add — the main kobject add function, bestie. like the main character of adding kobjects fr fr 👑

---

✨ SYNOPSIS ✨

int kobject_add (struct kobject *kobj , struct kobject *parent , const char *fmt , ... );

---

🎀 ARGUMENTS 🎀

• kobj — the kobject you're adding, the whole point of the function, the star of the show ⭐
• parent — pointer to the parent of the kobject. yes it can be NULL, we'll get to that, don't panic 🙈
• fmt — format to name the kobject with. that's how it gets its lil name 🏷️
• ... — variable arguments, the extra lil guys that feed into that format 🫶

---

🌸 DESCRIPTION 🌸

okay so here's the vibe: the kobject name gets set, and the kobject gets added to the kobject hierarchy, all inside this one function. iconic behavior honestly ✨

now the parent situation, pay attention because this is the part people mess up:

• if parent is set, then the parent of kobj will be set to it. simple, slay 💅
• if parent is NULL, then the parent of kobj will be set to the kobject associated with the kset assigned to this kobject. yes that's a whole chain, i know 😭
• and if no kset is assigned to the kobject, then the kobject will be located in the root of the sysfs tree. like it just moves into the sysfs family home 🏡

⚠️ note, no "add" uevent will be created with this call. so you, the caller, have to set up all of the necessary sysfs files for the object and then call kobject_uevent with the UEVENT_ADD parameter to make sure userspace is properly notified of this kobject's creation. don't skip this, bestie, userspace needs to know 👀

if this function returns success, kobject_put must also be called in order to properly clean up the memory associated with the object. no cap. 🧹

in short — once this function is called, kobject_put MUST be called when the use of the object is finished in order to properly free everything. like, uppercase must. periodt. 🔥

---

💀 RETURN 💀

if this function returns an error, kobject_put must be called to properly clean up the memory associated with the object. yes, even on the fail path, that's the whole bit 🙃

🚨 under no instance should the kobject that is passed to this function be directly freed with a call to kfree — that can leak memory. do not do it. i'm begging. that's the one thing that'll have you up at 3am debugging 😭💀

---

🦋 SEE ALSO 🦋

kernel file ./lib/kobject.c — go read it, it's giving lore 📖

and then the whole friend group:

kobject_namespace(9), kobject_get_ownership(9), kobject_get_path(9), kobject_set_name_vargs(9), kobject_set_name(9), kobject_init(9), kobject_init_and_add(9), kobject_rename(9), kobject_move(9), kobject_del(9), kobject_get(9), kobject_put(9), kobject_create(9), kobject_create_and_add(9), kset_init(9), kset_register(9), kset_unregister(9), kset_find_obj(9), kset_create(9), kset_create_and_add(9)

---

okay that's the whole page bestie, tysm for reading 🫶 this one lives in ./lib, dated October 2026, and it's the kobject_add(9) page — go forth and add your kobjects responsibly 💖✨🎀