STRUCT SUBSYS_INTERFACE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct_subsys_interface(9) β€” like, the whole Kernel API Manual thing, but make it make sense

okay bestie, sit down, grab a strawberry drink πŸ“, because we're talking about struct subsys_interface from the Kernel API Manual β€” and honestly? she's giving supporting character who secretly runs the whole group chat. no cap. πŸ’–


✨ NAME ✨

struct subsys_interface β€” interfaces to device functions 🫢

like, literally just that. interfaces. to device functions. iykyk.


πŸŽ€ SYNOPSIS πŸŽ€

here's the shape of her, character for character, no edits, no vibes-based "fixes":

struct subsys_interface {
    const char *name;
    const struct bus_type *subsys;
    struct list_head node;
    int (*add_dev)(struct device *dev, struct subsys_interface *sif);
    void (*remove_dev)(struct device *dev, struct subsys_interface
*sif);
 };

she's small. she's tidy. she has two function pointers and she knows how to use them. πŸ’…


🌸 Members 🌸

let's do a vibe check on every single field, one by one, because nobody gets skipped in this house:

  • name β€” the name of the device function ✨ that's it, that's the whole job, and she does it iconically
  • subsys β€” the subsystem of the devices to attach to πŸ¦‹ (note the type up top: const struct bus_type *subsys β€” it's a bus type, keep that in mind)
  • node β€” the list of functions registered at the subsystem πŸŽ€ so the subsystem keeps a little list of all the functions hanging out on it
  • add_dev β€” device hookup to device function handler πŸ”₯ this is your int (*add_dev)(struct device *dev, struct subsys_interface *sif); β€” returns an int, takes a device and a sif
  • remove_dev β€” device hookup to device function handler 🌈 yep, same description as add_dev, because that's literally what the manpage says, and it's the void (*remove_dev)(struct device *dev, struct subsys_interface *sif); counterpart. one adds, one removes. balance. 🧚

πŸ’œ Description πŸ’œ

so what is she, actually?

Simple interfaces attached to a subsystem. that's the whole thesis, bestie. πŸ“

Multiple interfaces can attach to a subsystem and its devices β€” not just one, multiple, she's not possessive. 🌸

and here's the part that matters, the main character distinction: unlike drivers, they do not exclusively claim or control devices. 🚨 like, drivers are out here fighting over devices like it's the last seat in the cafeteria, and interfaces are just vibing. they don't claim. they don't control. they simply exist. we love a low-drama queen. πŸ‘‘

Interfaces usually represent a specific functionality of a subsystem/class of devices. so think "this is the thing this subsystem does" β€” she's the specialty, the niche, the little extra flavor. πŸ“

okay but fr fr don't @ me about drivers here β€” the manpage said "they do not exclusively claim or control devices" and i'm just the messenger, bestie. πŸ’€

⭐ SEE ALSO ⭐

okay this list is long long, but we do not skip anyone in this group chat. every single one of these gets a shoutout. 🫢

Kernel file ./include/linux/device.h:

yeah. thirty-eight of them. i counted. not me doing homework for a manpage 😭 but every single one is here and none of them got left on read. πŸ’…


and that's the whole page! πŸ¦‹ she lives in ./include/linux and the version/date stamped on this read of the page is October 2026 β€” so if you're reading this from the future, hi, love you, hope your subsystem is thriving. mwah. πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from