ptem's limitations

[Guy Harris]

In article <1991May20.145454.682 at arizona.edu> cat at 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).