tty: add EXTPROC support for LINEMODE
in [Kernel]
|
Prev: [PATCH 0/2] tty: add EXTPROC support for LINEMODE
Next: [PATCH 0/1] (Was: Fix a race in pid generation that causes pids to be reused immediately.)
From: Chris Adams on 15 Jun 2010 21:30 Once upon a time, Alan Cox <alan(a)lxorguk.ukuu.org.uk> said: >> +#define EXTPROC 0x10000000 > >For Alpha this value should match OSF if possible. Since I'm reading this on an Alpha right now, I figured I'd do my bit to help out. As far as I can tell, Tru64 5.1B doesn't define this, nor does the above value match any of the Tru64-defined local flags. -- Chris Adams <cmadams(a)hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Derek Fawcus on 16 Jun 2010 11:30 On Tue, Jun 15, 2010 at 01:23:43PM -0700, Howard Chu wrote: > > Closest thing I've found so far is for HPUX 11i Version 2: > http://docs.hp.com/en/B2355-90848docs/B2355-90848docs.pdf > > TIOCREMOTE This ioctl puts the STREAMS pty in and out of Remote Mode. When > TIOCSIGNAL This ioctl allows the master process to send a signal to the slave > <<<< > > TIOCREMOTE seems to be the SVR4 analogue to TIOCPKT without any of the useful parts; it doesn't include the prefix > byte, so it doesn't provide any state change information. TIOCREMOTE is also supported on BSDs. A program I've been playing with on and off for a few years uses it (on solaris, FreeBSD, Darwin). That in combination with turning off all output post processing, and then regularly sampling the status of the pty for the following generally works: static int internal_get_modes (int fd, int *modep) { int modes = 0; if (tcgetattr(fd, &tty_mode) < 0) return 0; if (tty_mode.c_lflag & ICANON) modes |= MODE_CANON; else if (tty_mode.c_lflag & ISIG) modes |= MODE_CBREAK; else modes |= MODE_RAW; if (tty_mode.c_lflag & ECHO) modes |= MODE_ECHO; if (tty_mode.c_cc[VINTR] != vdisable) modes |= MODE_INTR; if (tty_mode.c_cc[VQUIT] != vdisable) modes |= MODE_QUIT; if (tty_mode.c_cc[VSUSP] != vdisable) modes |= MODE_SUSP; *modep = modes; return 1; } There is obviously a race condition in detecting the change in the above, but usually this is only an issue when starting/stopping certain curses apps, and can be handled by the various app redraw command. Currently for Linux, I disable echo before feeding characters to the pty, then restore it to its previous state. So REMOTE mode would be useful. Sending signals to the terminal group is different for BSD/solaris/Linux: int master_signal_tcpgrp (int master_fd, unsigned signo) // BSD { return ioctl(master_fd, TIOCSIG, signo); } int master_signal_tcpgrp (int master_fd, unsigned signo) // Linux { pid_t tcpgrp; tcpgrp = tcgetpgrp(master_fd); if (tcpgrp == -1) { return -1; } return kill(-tcpgrp, signo); } int master_signal_tcpgrp (int master_fd, unsigned signo) // SVR4 { return ioctl(master_fd, TIOCSIGNAL, signo); } Now for a notification type packet mode extension, something which provided the information extracted in the above set of MODE change indications would be useful, since it would remove the race condition. i.e. a completely different interpretation of the packet when supplying the control info. DF -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Howard Chu on 17 Jun 2010 16:10 Ping, any further advice on these issues? Howard Chu wrote: > Alan Cox wrote: >>> diff --git a/arch/alpha/include/asm/termbits.h b/arch/alpha/include/asm/termbits.h >>> index ad854a4..879dd35 100644 >>> --- a/arch/alpha/include/asm/termbits.h >>> +++ b/arch/alpha/include/asm/termbits.h >>> @@ -180,6 +180,7 @@ struct ktermios { >>> #define FLUSHO 0x00800000 >>> #define PENDIN 0x20000000 >>> #define IEXTEN 0x00000400 >>> +#define EXTPROC 0x10000000 >> >> For Alpha this value should match OSF if possible. OSF didn't define this flag, nor did it assign that particular bit to any purpose. Is that good enough? >>> + if (cs& TIOCPKT_IOCTL) { >>> + c = sizeof(struct termios); >>> + if (c> nr) >>> + c = nr; >>> + copy_to_user(b, tty->link->termios, c); >>> + nr -= c; >>> + b += c; >>> + } >> >> This is where the wheels come off the bus. >> >> The kernel use struct ktermios which is what tty->link->termios is >> >> The C library presents this via struct termios which is a glibc invention >> dependant on the C library and which is converted by libc from struct >> termios or struct termios2 depending on your C library >> >> How you fix that given a broken by design historic Unix interface which >> pastes arbitary struct termios objects into the data stream is an >> interesting question - doubly so when like most Unixen we have also have >> extended terminal attributes as well (termiox) > > Are you suggesting that this is completely unfixable/unworkable? Would it be > sufficient to use kernel_termios_to_user_termios() ? > Actually using kernel_termios_to_user_termios_1(). In all supported architectures this structure is basically aligned with but smaller than the userland struct termios. As such it will leave any unused fields unwritten in the user struct. This usually means it will leave c_ispeed and c_ospeed unset in the user struct, but that's a don't-care anyway since we're only talking about ptys here, and changing the speed (besides setting it to zero) is irrelevant for ptys. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 17 Jun 2010 16:50 > >> For Alpha this value should match OSF if possible. > > OSF didn't define this flag, nor did it assign that particular bit to any > purpose. Is that good enough? Fine > > Are you suggesting that this is completely unfixable/unworkable? Would it be > > sufficient to use kernel_termios_to_user_termios() ? I don't see a way to fix it sanely > > > Actually using kernel_termios_to_user_termios_1(). In all supported > architectures this structure is basically aligned with but smaller than the > userland struct termios. The relationship isn't quite so simple and it may change in the future, so this seems to be a very bad idea. Besides which syscalls are *cheap* so simply notifying someone to reread the terminal data they care about should be fine. In that sense it seems SVR4 got it right. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Howard Chu on 17 Jun 2010 17:30
Alan Cox wrote: >>>> For Alpha this value should match OSF if possible. >> >> OSF didn't define this flag, nor did it assign that particular bit to any >> purpose. Is that good enough? > > Fine > >>> Are you suggesting that this is completely unfixable/unworkable? Would it be >>> sufficient to use kernel_termios_to_user_termios() ? > > I don't see a way to fix it sanely > >>> >> Actually using kernel_termios_to_user_termios_1(). In all supported >> architectures this structure is basically aligned with but smaller than the >> userland struct termios. > > The relationship isn't quite so simple and it may change in the future, > so this seems to be a very bad idea. Besides which syscalls are *cheap* > so simply notifying someone to reread the terminal data they care about > should be fine. In that sense it seems SVR4 got it right. OK. I'm fine with only setting a bit in the packet header, and letting the application do an ioctl/tcgetattr to discover the actual state. Next question is, should this bit still be called TIOCPKT_IOCTL (which BSD uses) or should it be called something else, since the behavior is not the same as BSD? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |