Messages in this thread | | | Date | Sun, 25 Mar 2012 17:14:37 +0200 | From | Richard Weinberger <> | Subject | Re: TTY: tty_port questions |
| |
Am 25.03.2012 16:51, schrieb Alan Cox: > On Sat, 24 Mar 2012 23:20:01 +0000 > Al Viro <viro@ZenIV.linux.org.uk> wrote: > >> On Mon, Mar 12, 2012 at 11:48:32AM +0000, Alan Cox wrote: >> >>>>> It will be. In order to fix the tty locking mess we need to shove a lot >>>>> of stuff whose lifetime is the lifetime of the physical port somewhere >>>>> else - the tty_port is that structure. >>>>> >>>> >>>> "It will be" in terms of "not now"? ;-) >>> >>> As in, it's the very next step on. >> >> FWIW, uml console in default config is basically "start xterm for each VC". >> What do you suggest to do on vhangup() on one of those? > > What posix says must happen. Which is that the running processes get a > hangup. So a vhangup() would ensure there were no old apps on the UML > guess talking to the xterm (eg stealing login credentials, or abusing > TIOCSTI etc).
Looks like Debian's /bin/login is violating POSIX. AFACT it does not call vhangup() at all.
> The fact it's an xterm isn't really relevant. That's just the physical > interface and vhangup is about breaking the logical link. The xterm would > continue, no reason for it to do otherwise I can see ? >
As I wrote in my very first mail, if I implement tty_operations->hangup() a vhangup() closes the current TTY and the shiny new login shell dies because read/write() returns EIO.
So, the question is whether tty_port is not suitable for consoles or my driver (see first mail in thread) is broken.
Thanks, //richard
[unhandled content-type:application/pgp-signature] | |