cat@pluto.dss.com (Iain Wacey) (05/21/91)
of some limitation of ptem. It does not handle flow control leaving it to any lower module or driver to handle STOPI messages from ldterm. Ptem also doesn't deal with parity. Has anyone else run into these problems? If so how did you get around them? Has anyone written a replacement for ptem that handles these things. In search of a real psuedo physical terminal. Iain Wacey cat@pluto.dss.com
cat@pluto.dss.com (Iain Wacey) (05/21/91)
I have been using ptem and ldterm to provide a terminal like Message-ID: <4333@pluto.dss.com> Date: 20 May 91 20:42:56 GMT Followup-To: comp.unix.wizards Organization: Datability Software Systems, New York, NY Lines: 9 Xref: usc comp.unix.wizards:26796 comp.unix.programmer:1964 of some limitation of ptem. It does not handle flow control leaving it to any lower module or driver to handle STOPI messages from ldterm. Ptem also doesn't deal with parity. Has anyone else run into these problems? If so how did you get around them? Has anyone written a replacement for ptem that handles these things. In search of a real psuedo physical terminal. Iain Wacey cat@pluto.dss.com
cat@pluto.dss.com (Iain Wacey) (05/21/91)
I have been using ptem and ldterm to provide a terminal like Message-ID: <4333@pluto.dss.com> Date: 20 May 91 20:42:56 GMT Followup-To: comp.unix.wizards Organization: Datability Software Systems, New York, NY Lines: 9 Xref: arizona comp.unix.wizards:1890 comp.unix.programmer:1925 of some limitation of ptem. It does not handle flow control leaving it to any lower module or driver to handle STOPI messages from ldterm. Ptem also doesn't deal with parity. Has anyone else run into these problems? If so how did you get around them? Has anyone written a replacement for ptem that handles these things. In search of a real psuedo physical terminal. Iain Wacey cat@pluto.dss.com
cat@pluto.dss.com (Iain Wacey) (05/21/91)
I have been using ptem and ldterm to provide a terminal like Message-ID: <4333@pluto.dss.com> Date: 20 May 91 20:42:56 GMT Followup-To: comp.unix.wizards Organization: Datability Software Systems, New York, NY Lines: 9 Xref: emory comp.unix.wizards:1912 comp.unix.programmer:2123 of some limitation of ptem. It does not handle flow control leaving it to any lower module or driver to handle STOPI messages from ldterm. Ptem also doesn't deal with parity. Has anyone else run into these problems? If so how did you get around them? Has anyone written a replacement for ptem that handles these things. In search of a real psuedo physical terminal. Iain Wacey cat@pluto.dss.com
cat@pluto.dss.com (Iain Wacey) (05/21/91)
I have been using ptem and ldterm to provide a terminal like Message-ID: <4333@pluto.dss.com> Date: 20 May 91 20:42:56 GMT Followup-To: comp.unix.wizards Organization: Datability Software Systems, New York, NY Lines: 9 of some limitation of ptem. It does not handle flow control leaving it to any lower module or driver to handle STOPI messages from ldterm. Ptem also doesn't deal with parity. Has anyone else run into these problems? If so how did you get around them? Has anyone written a replacement for ptem that handles these things. In search of a real psuedo physical terminal. Iain Wacey cat@pluto.dss.com
guy@auspex.auspex.com (Guy Harris) (05/23/91)
In article <1991May20.145454.682@arizona.edu> cat@pluto.dss.com (Iain Wacey) writes: Some stuff with the first line of the message in the middle of the headers. You might want to fix your news software, or tell whoever maintains it to fix it.... >of some limitation of ptem. It does not handle flow control >leaving it to any lower module or driver to handle STOPI >messages from ldterm. It doesn't handle flow control coming into the pseudo-tty, no; it leaves that up to the streams mechanism to handle, just as other pseudo-tty mechanisms do. >Ptem also doesn't deal with parity. The data path that a pseudo-terminal sends its data over isn't an asynchronous serial line, as is the case with real terminals; it's generally called "main memory", and it often not only has parity but ECC; why do you want "ptem" to deal with the parity or ECC on main memory? The same is true of the BSD pseudo-tty mechanism, BTW; has anybody *ever* implemented a pseudo-tty mechanism that "deals with parity" in that sense? If so, why? If you're ultimately connecting the process on the controller side of the pseudo-tty to a real serial line, and want to handle parity on the real serial line, let the hardware on the real serial line do it for you. If you want mode settings done on the pseudo-tty propagate through to the real serial line, have the process on the controller side request that M_IOCTL messages be copied to it, and have it propagate settings done on the pseudo-tty to the serial port (although I remember hearing from somebody that the "ioctl snooping" code has bugs in it).