module_driver(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… module_driver(9) β€” the kernel API manual, bestie edition πŸŽ€

Okay so real talk: this one lives in the kernel API manual and it's a macro, capital-M Macro, and she is here to save you from typing the same boring init/exit boilerplate forever. ✨


🌸 NAME 🌸

module_driver β€” the helper macro for drivers that don't do anything special in module init/exit. It eliminates a lot of boilerplate. Like, a lot. 🫢

Two things you absolutely cannot skip, bestie:

  • Each module may only use this macro once. One and done. No double-dipping. πŸ™ˆ
  • Calling it replaces module_init() and module_exit(). Not "adds to" β€” replaces. So don't go calling those too, okay?

✨ SYNOPSIS ✨

module_driver (__driver , __register , __unregister , ... );

That's the whole vibe. Four slots, one macro, zero drama. πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • __driver β€” the driver name. That's it, that's the whole description. Her name. πŸ‘‘
  • __register β€” the register function for this driver type. The "put it in the system" one. πŸ”₯
  • __unregister β€” the unregister function for this driver type. The "take it back out" one. πŸ’€
  • ... β€” additional arguments to be passed to __register and __unregister. Extra toppings, both ways. πŸ“

🌈 DESCRIPTION 🌈

Bestie, listen closely, this is the important part:

Use this macro to construct bus specific macros for registering drivers β€” and do not use it on its own. 🚨

It's giving "template for a template". She's the blueprint you build other macros out of, not something you slap directly into your driver. Respect the pipeline. ✨


🧚 SEE ALSO 🧚


πŸ’– Go read struct device_driver(9) next, iykyk. It's the main character of this whole friend group.

Okay that's the page!! Mwah πŸ’‹ β€” this one's from ./include/linux/device, dated October 2026, and honestly? She ate. Periodt. πŸŒŸπŸŽ€πŸ’œ

πŸ“¦ where this page comes from