fwctl_unregister(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME πŸ’…

okay so this is fwctl_unregister(9), straight out of the Kernel API Manual, and it's literally the β€œunregister a device from the subsystem” girlie. No cap. πŸ¦‹

🫢 SYNOPSIS 🫢

void fwctl_unregister (struct fwctl_device *fwctl );

πŸŽ€ ARGUMENTS πŸŽ€

  • fwctl β€” a previously allocated and registered fwctl_device. Like, it already had its moment; now we're unregistering it. πŸ’…

πŸ’… DESCRIPTION πŸ’…

This function undoes fwctl_register. That's the whole vibe. On return, no driver ops will be called β€” not a single one. 😌

The caller still has to call fwctl_put to actually free the fwctl. Unregister does not free it for you, bestie. 🫢

Here's the lowkey wild part: unregister will return even if userspace still has file descriptors open. Yep, it just dips. It will call ops->close_uctx on any open FDs, and after return no driver op will be called. The FDs remain open, but all fops will return -ENODEV. So they're still there, just doing the absolute least. πŸ’€

The design of fwctl allows this sort of disassociation of the driver from the subsystem primarily by keeping memory allocations owned by the core subsystem. That's the main character move. Both the fwctl_device and fwctl_uctx can be freed without requiring a driver callback, and this allows the module to remain unlocked while FDs are open. Iconic behavior, honestly. ✨

πŸ‘€ SEE ALSO πŸ‘€

  • Kernel file ./drivers/fwctl/main.c β€” go read it, iykyk πŸ“–
  • fwctl_register(9) β€” the prequel, fr fr 🌸

Signed with so much love by ./drivers/fwctl, October 2026, all about fwctl_unregister(9) πŸ’–πŸŽ€

πŸ“¦ where this page comes from