* Furthermore, the DRM core provides dynamic char-dev lookups. For each
 * interface registered on a DRM device, you can request minor numbers from DRM
 * core. DRM core takes care of major-number management and char-dev
 * registration. A stub ->open() callback forwards any open() requests to the
 * registered minor.

This is terrifying.

So every subsystem that needs multiple drivers to handle devices of the same type (think sound, graphics...) hacked together its own homebrew version of associating drivers to minors.

And the way they do that is by registering a common driver to the major number (viewable in /proc/devices) and having a stub open impl that patches the fops of the passed file pointer to refer to the driver's

Meaning that at any point, the driver that a given major,minor pair refers to might change. Between calls to open. There might in fact be two different processes alive that have the same major,minor pair open, at the same path, but with different fops.

I hate this.

Thankfully every fops has an owner ()

struct file_operations {
    struct module *owner;
// ...

So I will have to write a patch (or maybe kmod might work) for the kernel to, given a PID + fd, output a symlink to /sys/module/ or something.

I mean, if I can write a patch, to shove it into proc fdinfo. Otherwise I'd need to make a new filesystem and hope that I can access this info, ig.

It goes struct task_struct -> .files -> struct files_struct -> files_lookup_fd_locked -> struct file -> .f_op -> struct file_operations -> .owner -> struct module -> .name

Essentially. So I need to get a task_struct from a PID. procfs already gets a task_struct passed in fdinfo, lol. It's impl'd in fs/proc/fd.c, seq_show. I could trivially extend this. It'd be a simple patch. In fact I already wrote it as I was writing this fedi post, just gotta test it :D