[lkml]   [2012]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: TTY: tty_port questions
    Am 25.03.2012 16:51, schrieb Alan Cox:
    > On Sat, 24 Mar 2012 23:20:01 +0000
    > Al Viro <> 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.


    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2012-03-25 17:17    [W:0.180 / U:3.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site