Re: term & user space console

[Thomas Bushnell, BSG]

tb@becket.net (Thomas Bushnell, BSG) writes:

> All input parity checking is done by term itself, and the device
> should just do none (or at least provide a way to turn it off).

Oh, things aren't quite right here yet.

First, note that the arg to input_character is a full int.  A simple
char is not enough; if the incoming byte has 8 bits and parity, then
that's 9 bits and it won't fit.

There is nothing in serial communication to distinguish parity from an
extra bit.  If the user sets INPCK, then the last bit coming in is
parity, and gets checked.  If ISTRIP is set, then any parity bit is
stripped.

What the lower half should do is treat the parity bit like just
another bit and provide it as part of the data.  Because it can't
distinguish a parity bit from a data bit, it can't treat it as
anything but the most significant bit of the result.

If a short byte comes in, it should pad with zeros.  If a long byte
comes in, it should probably take the first N bits as data, and make
the rest zeroes.  Both these solutions result in the parity bit as
seen by munge.c to be zero; that means that at least it won't break
the no-parity case.  It's not important what exactly happens here,
however, and there may well be some hardware which simply treats all
such cases as framing errors.

Then, munge.c needs to DTRT.  Unfortunately, the current code is buggy
in that it always assumes that the parity bit is at 0x80.  To fix the
bug, reference needs to be made to the current byte side by the
relevant checks in checkoddpar, checkevenpar, and the ISTRIP handling.

Thomas