hvc_iucv_notifier_hangup(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ NAME πŸŽ€

okay so bestie, welcome to the Kernel API Manual page for hvc_iucv_notifier_hangup(9) β€” it’s the HVC notifier for TTY hangups. That’s the whole vibe: TTY hangup happens, and this routine handles the notifier moment. πŸ’…

✨ SYNOPSIS ✨

void hvc_iucv_notifier_hangup (struct hvc_struct *hp , int id );

🫢 ARGUMENTS 🫢

  • hp β€” Pointer to the HVC device (struct hvc_struct). This is the device bestie in question. πŸ¦‹
  • id β€” Additional data (originally passed to hvc_alloc): the index of an struct hvc_iucv_private instance. It’s literally the little identifier that came in through hvc_alloc. ✨

πŸ’… DESCRIPTION πŸ’…

This routine notifies the HVC back-end that a tty hangup (carrier loss, virtual or otherwise) has occurred. So yeah, it’s giving β€œheads up, the tty hung up” energy. πŸ“£

The z/VM IUCV HVC device driver ignores virtual hangups (vhangup) to keep an existing IUCV communication path established. (Background: vhangup is called from user space (by getty or login) to disable writing to the tty by other applications). So it’s very much a β€œnot today, virtual hangup” situation. πŸ™ˆ

If the tty has been opened and an established IUCV path has been severed (we caused the tty hangup), the function calls hvc_iucv_cleanup. That’s the cleanup era, periodt. 🧹

Locking: struct hvc_iucv_private->lock

πŸ”₯ SEE ALSO πŸ”₯

The kernel file is ./drivers/tty/hvc/hvc_iucv.c, and here’s the full bestie roll call, in order:

okay that’s the page, bestie β€” source/version tag is ./drivers/tty/hvc, date is October 2026, and we were just reading hvc_iucv_notifier_hangup(9). mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from