CONFIG_INTRHOOK(9)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

πŸ’… CONFIG_INTRHOOK(9) β€” like, the interrupt-hook situation

okay bestie so this is a page from the Kernel Developer's Manual (CONFIG_INTRHOOK(9)) and it's literally about scheduling a function to run after interrupts are enabled but before root gets mounted. yes it's as specific as it sounds and yes it's iconic πŸŽ€


✨ NAME ✨

config_intrhook β€” schedule a function to be run after interrupts have been enabled, but before root is mounted 🫢


🌸 SYNOPSIS 🌸

#include <sys/kernel.h>

typedef void (*ich_func_t)(void *arg);

int
config_intrhook_establish(struct intr_config_hook *hook);

void
config_intrhook_disestablish(struct intr_config_hook *hook);

int
config_intrhook_drain(struct intr_config_hook *hook);

void
config_intrhook_oneshot(ich_func_t func, void *arg);

πŸ¦‹ DESCRIPTION πŸ¦‹

So config_intrhook_establish() schedules a function to be run after interrupts have been enabled, but before root is mounted. and if the system has already passed this point in its initialization? the function is called immediately. no waiting, no queue, just vibes ✨

config_intrhook_disestablish() removes the entry from the hook queue. that's it, that's the whole thing πŸ’…

config_intrhook_drain() removes the entry from the hook queue in a safe way. here's the tea:

  • if the hook is not currently active, it removes hook from the hook queue and returns ICHS_QUEUED
  • if the hook is active, it waits for the hook to complete before returning ICHS_RUNNING
  • if the hook has previously completed, it returns ICHS_DONE
🚨 okay so listen: because a config_intrhook is undefined prior to config_intrhook_establish(), this function may only be called after that function has returned. periodt.

config_intrhook_oneshot() schedules a function to be run as described for config_intrhook_establish() β€” but the entry is automatically removed from the hook queue after that function runs 🧚 this is appropriate when additional device configuration must be done after interrupts are enabled, but there's no need to stall the boot process after that. no cap.

πŸ’€ config_intrhook_oneshot() allocates memory using M_WAITOK β€” do not call this while holding any non-sleepable locks. that's a real warning bestie, don't do it πŸ™ˆ

now, the main character energy of this whole page:

before root is mounted, all the previously established hooks are run. the boot process is then stalled until all handlers remove their hook from the hook queue with config_intrhook_disestablish(). then the boot process proceeds to attempt to mount the root file system. 🌈

any driver that can potentially provide devices they wish to be mounted as root must use either this hook, or probe all these devices in the initial probe. because interrupts are disabled during the probe process, many drivers need a method to probe for devices with interrupts enabled β€” and that's the whole point, iykyk πŸŽ€


πŸ’– the struct πŸ’–

the requests are made with the intr_config_hook structure. this structure is defined as follows:

struct intr_config_hook {
        TAILQ_ENTRY(intr_config_hook) ich_links;/* Private */
        ich_func_t      ich_func;               /* function to call */
        void            *ich_arg;               /* Argument to call */
};

storage for the intr_config_hook structure must be provided by the driver. it must be stable from just before the hook is established until after the hook is disestablished. don't let it wander off, it has a job to do 🫢

specifically, hooks are run at SI_SUB_INT_CONFIG_HOOKS(), which is immediately after the scheduler is started, and just before the root file system device is discovered. iconic timing honestly πŸ‘‘


⭐ RETURN VALUES ⭐

  • a zero return value means the hook was successfully added to the queue (with either deferred or immediate execution) πŸŽ‰
  • a non-zero return value means the hook could not be added to the queue because it was already on the queue 😭

πŸ’œ SEE ALSO πŸ’œ


🌺 HISTORY 🌺

these functions were introduced in FreeBSD 3.0 with the CAM subsystem, but they're available for any driver to use. so yes, they've been slaying since forever πŸ’…


πŸ“ AUTHORS πŸ“

the functions were written by Justin Gibbs <gibbs@FreeBSD.org>. this manual page was written by M. Warner Losh <imp@FreeBSD.org>. absolute legends, we love them πŸ‘‘


and that's the whole page bestie πŸ’– this came from Debian, dated March 8, 2021 β€” go forth and schedule your hooks responsibly, mwah πŸŽ€βœ¨

πŸ“¦ where this page comes from