tty_open(9)

📦 version 7.3.1, in nixpkgs unstable

💖 tty_open(9) — Kernel API Manual ✨

okay so bestie, buckle up, because this is the tea on tty_open from the kernel API manual. it's a kernel function, it's iconic, and it's about to open a tty device for you. let's get into it 🎀

✨ NAME ✨

tty_open — open a tty device 🦋

🌸 SYNOPSIS 🌸

int tty_open (struct inode *inode , struct file *filp );

💅 ARGUMENTS 💅

  • inode — the inode of the device file, aka the little ID card for the thing you're opening 🪪
  • filp — the file pointer to the tty, the actual handle you get to hold 🫶

🔥 DESCRIPTION 🔥

so here's the vibe: tty_open and tty_release are the two besties that keep up the tty count, and that count holds the number of opens that have been done on a tty. lowkey important. the reason they can't just use the inode-count is that different inodes might point to the same tty — and then your count would be a whole lie. 🙈 not slay.

open-counting is needed for pty masters, and it's also how serial lines are kept track of: DTR is dropped when the last close happens. that's the rule, no cap. (and just so you know — this is not done solely through tty->count, now. — Ted 1/27/92 📝)

the termios state of a pty gets reset on the first open, so that settings don't persist across reuse. clean slate energy, we love to see it ⭐

🌈 Locking (the part where you pay attention)

  • tty_mutex protects tty, tty_lookup_driver and tty_init_dev. 👑
  • tty->count should protect the rest.
  • ->siglock protects ->signal/->sighand

⚠️ NOTE ⚠️

the tty_unlock/lock cases without a ref are only safe due to tty_mutex 💀 like, that's the only thing holding it together, bestie. respect the mutex.

🧚 SEE ALSO 🧚

Kernel file ./drivers/tty/tty_io.c — and the whole extended friend group:

and that's the whole page, bestie 💜 this one came out of ./drivers/tty, dated October 2026, and it's filed under tty_open(9) — go forth and open ttys responsibly, ily 🍓🌸

📦 where this page comes from