DEVFS_CDEVPRIV(9)

💅 DEVFS_CDEVPRIV 💅

okay so this is a page from the Kernel Developer's Manual — section 9, kernel land, bestie. we're talking devfs_set_cdevpriv, devfs_get_cdevpriv, devfs_clear_cdevpriv, and devfs_foreach_cdevpriv — the whole little squad that manages per-open filedescriptor data for devices. it's giving ✨ device driver bookkeeping ✨ and honestly? kind of iconic.

---

🎀 NAME 🎀

devfs_set_cdevpriv, devfs_get_cdevpriv, devfs_clear_cdevpriv, devfs_foreach_cdevpriv — these four besties literally manage per-open filedescriptor data for devices. that's the whole vibe. no notes. 💖

---

🌸 SYNOPSIS 🌸

#include <sys/param.h>
#include <sys/conf.h>

typedef void d_priv_dtor_t(void *data);

int
devfs_get_cdevpriv(void **datap);

int
devfs_set_cdevpriv(void *priv, d_priv_dtor_t *dtr);

void
devfs_clear_cdevpriv(void);

int
devfs_foreach_cdevpriv(struct cdev *dev,
    int (*cb)(void *data, void *arg), void *arg);

like, just look at it. the d_priv_dtor_t typedef is a void function taking void *data. she's a destructor. she's a whole vibe. 🦋

---

💜 DESCRIPTION 💜

so the devfs_xxx_cdevpriv() family lets your cdev driver methods associate some driver-specific data with each user process open(2) of the device special file. one open = one lil data bundle. that's the entire concept, no cap. 🫶

lowkey important though: currently, functioning of these functions is restricted to the context of the cdevsw switch method calls performed as devfs(4) operations in response to system calls that use filedescriptors. so like... you can't just call these wherever. vibe check first, okay? 💀

✨ what each one does ✨

• devfs_set_cdevpriv() — associates data pointed by priv with the current calling context (the filedescriptor). slay. 💅
• devfs_get_cdevpriv() — retrieves that data later, possibly from another call performed on this filedescriptor. she remembers. 👑
• devfs_clear_cdevpriv() — disassociates previously attached data from context. immediately after devfs_clear_cdevpriv() finishes operating, the dtr callback is called, with the private data supplied as the data argument. and bestie — devfs_clear_cdevpriv() will also be called if the open callback function returns an error code. 😭 it's got your back like that.
• on the last filedescriptor close, the system automatically arranges a devfs_clear_cdevpriv() call. no manual cleanup needed. periodt. ✨

🍓 return values 🍓

if successful, the functions return 0. iconic.

devfs_set_cdevpriv() returns these on error:

• [ENOENT] — the current call is not associated with some filedescriptor. 🙈
• [EBUSY] — the private driver data is already associated with the current filedescriptor. girl, it's taken. 💀

devfs_get_cdevpriv() returns these on error:

• [EBADF] — the current call is not associated with some filedescriptor. 💀
• [ENOENT] — the private driver data was not associated with the current filedescriptor, or devfs_clear_cdevpriv() was called. she's gone, babes. 😭

🌈 devfs_foreach_cdevpriv() 🌈

this one sequentially calls the function cb for each cdevpriv structure currently associated with the cdev device. the iterated cdevpriv data pointer and the user-supplied context arg are passed to the function cb. if cb returns a non-zero value, the iteration stops on that element — like, she's done, thank you. 🛑

devfs_foreach_cdevpriv() returns the return value from the last call to cb, or zero if no cdevpriv data is currently associated with the device. 💖

⚠️ real talk warning: the current implementation of the iterator makes it impossible to use any blockable locking inside the callback cb. not "discouraged", not "kinda sketchy" — impossible. do not try it. deadass. 💅

---

🦋 SEE ALSO 🦋

• close(2)
• open(2)
• devfs(4)

go read them, iykyk 📚✨

---

🌸 HISTORY 🌸

the devfs_cdevpriv() family of functions first appeared in FreeBSD 7.1. a vintage. an icon. a legend. 👑

---

okay that's the whole page bestie, you're officially educated 💖✨🎀🦋 — this masterpiece of a manpage came from the Debian crew, dated March 23, 2024, and it's filed under DEVFS_CDEVPRIV(9). mwah. 💅🌷