[ntp:hackers] Re: RAW mode in NTP.

David L. Mills mills at udel.edu
Thu Mar 16 20:20:30 UTC 2006


I have no problem with this, as I consider myself rescued from 25 years 
of inspired incompetence with SysV and 4.x. In short, the reason for raw 
mode in the first place is in dealing with ACTS and the NIST on-time 
character. Formerly, the motive was to preserve binary timestamps in the 
data as provided by a line discipline or streams module. While I know of 
no driver that needs to do this, somebody might want to switch between 
raw and canonical modes during regular operation.


Reg Clemens wrote:

> Dave:-
> 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
> fields.

More information about the hackers mailing list