tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Reparenting processes?



>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index