STRUCT KMOD_TEST_DEVICE_INFO(9)

🌸 STRUCT KMOD_TEST_DEVICE_INFO(9) 🌸

okay bestie, buckle up — this is a page from the Kernel API Manual and it's all about struct kmod_test_device_info, aka the thread info struct. lowkey iconic little record. let's get into it 💅

✨ NAME ✨

struct kmod_test_device_info — thread info 🧵

🦋 SYNOPSIS 🦋

here's the whole glow-up, character for character, no cap:

struct kmod_test_device_info {
    int ret_sync;
    struct file_system_type *fs_sync;
    struct task_struct *task_sync;
    unsigned int thread_idx;
    struct kmod_test_device *test_dev;
    bool need_mod_put;
 };

💖 Members 💖

• ret_sync — the return value if request_module is used, sync request for TEST_KMOD_DRIVER ✨
• fs_sync — the return value of get_fs_type for TEST_KMOD_FS_TYPE 🌸
• task_sync — the kthread's task_struct, or NULL if it's not running 🙈
• thread_idx — the thread ID, literally just the ID 🎀
• test_dev — the test device that the test is being performed under 👑
• need_mod_put — okay so some tests (get_fs_type is one of them) require putting the module (module_put(fs_sync->owner)) when done — otherwise you will not be able to unload the respective modules and re-test 😭. We use this to keep accounting of when we need this, and to help out in case we need to error out and deal with module_put on error. it's giving responsible bookkeeping fr fr 💀

heads up bestie: skip that module_put and your modules stay stuck loaded — no unloading, no re-testing. so like, don't 🫶

🌈 SEE ALSO 🌈

• Kernel file ./lib/test_kmod.c
• enum kmod_test_case(9)
• struct kmod_test_device(9)

and that's the whole page, bestie! 🎀 this lil masterpiece lives in ./lib, it's the October 2026 era, and it goes by struct kmod_..._device_info(9) 👑💜 periodt.