[ntp:hackers] RAW mode in NTP.

Reg Clemens reg at dwf.com
Wed Mar 15 04:47:24 UTC 2006


Since you are already not too happy with me for my questions
about the ATOM driver, and there was just a posting on
ntp-hackers about the release candidate NOT working because
of the setting of RAW mode in ntp_refclock.c, I'm going to
take on that topic so someone else wont have to get on
your s**t list.

The current problem has to do with the zeroing (or not
zeroing of fields in termio/termios in ntp_refclock.c .
This code (ntp_refclock) was a horrible mess, and you
cleaned it up.  However in the process, you removed some
of the zeroing of fields that was already there, and
it seems you claim that the current code is correct.

Let me state my option:

    (1) A real RAW mode hasn't existed since V6 Unix,
        since then we have emulated RAW mode with
        options in termio/termios.

    (2) RAW mode is usually taken to define a mode where
        two things happen:

        (a) The driver gives you your characters as
        they arrive (or in blocks if there is a
        stream of characters arriving with minimal
        delay between characters).

        (b) It does not change any of the characters,
        that is, it can be used for reading BINARY DATA.

The code, as you have it in ntp_refclock.c may do the first,
but does not do the second.

I'm not sure what drivers you are using (mabe they don't
need BINARY MODE), or what OS (I cant believe that any
OS would get this wrong), but:

I spent a few minutes this evening, checking both my SUN
and 4.4BSD documentation about RAW mode.  The wording in the
two is the same, and I have to assume that any other SysV
based documentation would have the same paragraphs, word
for word.

Looking at the TERMIOS(4) section of either of the above 
manuals (in my SUN manual the section is TERMIO), in the
NON-CANONICAL input section, they talk in terms of MIN and
TIME, which are, in fact

    MIN  = c_cc[VMIN]  = c_cc[6]
   TIME  = c_cc[VTIME] = c_cc[5]

and they state that if we set MIN = 1, and TIME=0, (which
you do), a pending read will be satisfied as soon as 1
character has been received.  So far so good.

However, just a paragraph earlier, these variables are described
as only having effect in NON-CANONICAL mode, and you have the
ICANON flag set in c_lflag just before the IF check where RAW
is being set.  I would have to suggest that this means that
the MIN is ignored.  If it is not, then your OS (whatever
that may be) is taking liberties with the definitions on
the man pages.

But even if you get the characters, its worse than that.

On the way down to the IF check where you set RAW mode, you
have set the following:

    c_iflag = IGNBRK | IGNPAR | ICRNL;

and they don't get cleared anywhere.  Now there is no reference
to ICANON in the definition of these options, so I have to
assume that they work in either CANONICAL or NON-CANONICAL
mode.  That being the case, the current code converts

   <CR> -> <LF>

(the other two options have to do with error conditions which
we can ignore for the current discussion,- the parity check
on the binary records should take care of any errors)

Bottom line, even if (when) we get the characters, binary
records will have been corrupted.


So, from my point of view, we want to set

    ttyp->c_cflag = CS8 | CLOCAL | CREAD;

which you do, and you set

    ttyp->c_oflag = 0;

but only on some paths thru the code, I feel safer zeroing
it again, just in case.

And finally the c_iflag, above, which I CLAIM needs to be
zeroed or else we don't get a binary transfer (this is what
I have seen on Linux and what Terje has seen on ?? ).

Thus the code I have proposed, reads

     if (lflags & LDISC_RAW) {
             ttyp->c_lflag = 0;
             ttyp->c_iflag = 0;
             ttyp->c_oflag = 0;
     /* leave c_cflag with CLOCAL, CREAD, C8 and SPEED */
             ttyp->c_cc[VMIN] = 1;

I'm not sure how you can argue with this, but feel free to
let me know why you would object to the zeroing of these

                                        reg at dwf.com

More information about the hackers mailing list