>> I've got the test program written. On 5.2/amd64 with /dev/ttyE1 as >> the test tty (no getty running on it, of course), output works just >> fine [...]
> I tried it too, on 9.1 amd64, and that worked too. I did not expect > that. While trying to write down why I thought that, I got even more > confused for a while, because there is stuff going on both with > vnodes for the ctty, and pointers to its struct tty, and they are not > handled together. True. > I'm looking at current-ish source, but I suppose this hardly ever > changes. I agree, because the code you quote looks a whole lot like the corresponding 5.2 code, including the split of TIOCSCTTY's functionality between tty.c and vfs_vnops.c. > I wonder what happens if a USB serial port is the ctty and it gets > removed... probably a dangling pointer. I think I have a USB serial port somewhere. I should try that under 5.2 to see what happens. Some parts of the tty code likely date from before dynamic detach and thus may not handle it well.... > so you can conceivably set a FIFO or a block device or a random raw > disk also as controlling tty? If its ioctl routine accepts TIOCSCTTY, yes. I would almost say that accepting TIOCSCTTY is the defining characteristic of things capable of becoming cttys...though not quite, because without a struct tty, it gets a bit confused. I suppose something accepting TIOCSCTTY without setting s_ttyp simply counts as a driver bug.... > Why the code for TIOCSCTTY is split in two parts remains unclear. To put it mildly! :-) > Maybe the existence of this split explains why session leaders are > not allowed to relinquish their ctty using TIOCNOTTY That made no sense to me either. Neither does the test that forbids process group leaders from setsid()ing. > [Stevens] "Advanced Programming in the UNIX Environment" from Stevens > is more explanatory about sessions etc (but it also says that BSD has > no session IDs, but by now NetBSD clearly does have them). At the time, I think, BSD did not have them. My impression is that POSIX created them by fiat, though presumably it actually drew them from somewhere. I'm not sure whether I think sessions are a good thing or not. > "... the hang-up signal is sent to the controlling process (the > session leader)" Really? I thought tty-generated SIGHUPs were sent to all processes in the tty's pgrp, regardless of sessions. Perhaps I need to go read more code. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
