DEVFS_CDEVPRIV(9)

💖 DEVFS_CDEVPRIV — the devfs_cdevpriv trilogy 💖

okay bestie, so this is DEVFS_CDEVPRIV(9) from the Kernel Developer's Manual, and it's literally about giving each open file descriptor of a device its own lil personal stash of data. no cap. let's get into it 🫶

✨ NAME ✨

devfs_set_cdevpriv, devfs_get_cdevpriv, devfs_clear_cdevpriv — manage per-open filedescriptor data for devices 🎀

🌸 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);

🦋 DESCRIPTION 🦋

so the devfs_xxx_cdevpriv() family of functions lets a cdev driver's methods attach some driver-specific data to each user open(2) of the device special file. like, one blob of vibes per open, yk? 💅

rn, these functions only work in the context of the cdevsw switch method calls that get performed as devfs(5) operations, in response to system calls that use filedescriptors. that's the vibe check. if you're not in that context, it's not giving.

devfs_set_cdevpriv() associates the data pointed to by priv with the current calling context (the filedescriptor). you can grab that data back later with devfs_get_cdevpriv() — possibly from a totally different call made on that same filedescriptor. obsessed with the continuity fr fr ✨

devfs_clear_cdevpriv() disassociates previously attached data from the context. and the moment devfs_clear_cdevpriv() finishes operating, the dtr callback gets called, with the private data passed in as its data argument. also!! devfs_clear_cdevpriv() gets called if the open callback function returns an error code. so like, automatic cleanup, iconic behavior 😌

and on the last filedescriptor close, the system automatically arranges a devfs_clear_cdevpriv() call. it just handles it. main character energy tbh 👑

if successful, the functions return 0.

😭 errors from devfs_set_cdevpriv()

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

🙈 errors from devfs_get_cdevpriv()

• [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. gone. vanished. not in the group chat anymore.

🌈 SEE ALSO 🌈

close(2), open(2), devfs(5)

⭐ HISTORY ⭐

the devfs_cdevpriv() family of functions first appeared in FreeBSD 7.1. vintage but make it slay 💜

🎀 bestie that's the whole page, no notes. this Debian-flavored rendering is dated December 2, 2015, and it lives in the DEVFS_CDEVPRIV(9) section of the Kernel Developer's Manual. mwah 💖✨🌸🦋💅