Xref: utzoo comp.unix.questions:23938 comp.unix.wizards:22986 comp.unix.xenix:12492 comp.unix.i386:7066
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!daver!ditka!mcdchg!ddsw1!beam!lucio
From: lucio@beam.UUCP (Lucio de Re)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix,comp.unix.i386
Subject: TTY line discipline
Message-ID: <2026@beam.UUCP>
Date: 16 Jul 90 14:12:33 GMT
Reply-To: lucio@proxima.UUCP
Organization: M-net Special Broadcast
Lines: 62


We first encountered this problem in Xenix (System V, Version 2.3.2), but
experimentation showed that it occurs in Intel Unix System V, Release 3.2.2
as well.

The symptoms are as follows: using the standard (and only?) line
discipline, the following termio settings had a strange side effect:

    n_ctrl.c_iflag &= ~(INLCR | IGNCR | ICRNL | IUCLC );
    n_ctrl.c_iflag |= IXOFF;
    n_ctrl.c_lflag &= ~(ICANON | ISIG);
    n_ctrl.c_cc[VINTR] = 255;   /*  these seem to disable ...  */
    n_ctrl.c_cc[VQUIT] = 255;   /*  ...                        */
    n_ctrl.c_cc[VERASE] = 255;  /*  ...                        */
    n_ctrl.c_cc[VKILL] = 255;   /*  ... the relevant function  */
    n_ctrl.c_cc[VMIN] = 1;      /*  character count         */
    n_ctrl.c_cc[VTIME] = 50;    /*  time limit              */

that is, a null character on input would trigger the timeout
condition. As a result, the null is swallowed by the line discipline
and cannot be received. If the timeout is set to zero, the problem
does not arise, and nulls are accepted as normal characters.

Unfortunately for us, we require both unprocessed input and timeouts;
we could compromise and use alarm calls to provide the timeout, but
the cost in system resources seems prohibitive (and is a kludge).

I had occasion to discuss this personally with a gentleman from SCO,
who was at the time guest at an exhibition, and he felt that this
behaviour should not be the case. We subsequently tested the behaviour
on a machine running Intel Unix System V Version 3.2.2 (albeit an
early BellTech release) and found the same effect.

A number of possibilities arise:
    (a) a fix to the existing line discipline may have removed
        the problem in kernels more recent than the ones we are using;
    (b) what we find problematic may be intentional and we may have to
        resort to a different line discipline to cater for our needs;
    (c) what we want may be impossible for reasons that we have
        overlooked.

To the NET I ask:
    (i)   is the behaviour I described intentional or erroneous?
    (ii)  Whether or not it is intentional, is it possible to add line
          disciplines to an existing device driver without requiring
          the source for the device driver (said SCO gentleman feels it
          has been done)?
    (iii) where can one find guidelines or alternative device drivers
          for the kernels we use that will make it possible for our
          requirements to be met?
    (iv)  if it should be imperative that we use alarm calls to satisfy
          our requirements, what would be the underlying cost in terms
          of kernel and other resources?
          (To expand here, we would have to issue an alarm call whenever
          one or more characters are input; a later alarm call would
          cancel the previous one, nevertheless we could land up with a
          ridiculous amount of overheads.)

Thanks very much to all who can provide us with some direction on
these points.

Lucio de Re (lucio@proxima.UUCP).