Re: [gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD

[Andy Walls]

On Fri, 2013-11-01 at 10:54 -0400, Greg Troxel wrote:
> Andy Walls <address@hidden> writes:
> 
> > On Fri, 2013-11-01 at 09:05 -0400, Greg Troxel wrote:
> 
> > From RFC2783 Section 3.4.2:
> > "A suitably privileged application may use time_pps_setparams() to set
> >    the parameters (mode bits and timestamp offsets) for a PPS source."
> >
> > So time_pps_setparams() can require privileges.
> 
> True, but in 3.4.1, third paragraph in DESCRIPTION it says
> "time_pps_setparams SHOULD be prohibited .. [if the fd is open only for
> reading]", which I read as a clue that "can write device" was the
> meaning of "suitable".  (Certainly it's within-spec to require more than
> that.)

I guess I think of O_RDWR vs O_RDONLY as orthogonal to privileged
operation, so it didn't stand out to me.


> >
> > IMO, RFC2783's doesn't prohibit setparams from being an unprivileged
> > operation, since it uses the weasel words "suitably privileged".
> 
> I didn't really see that as weasely, since the clear hint is "can write
> to the device".
> 
> What I can't figure out is what should happen when there is a single
> serial device and two processes open the same device (or the /dev/ppsN
> that corresponds to that device).  It would be entirely possible to have
> separate pps state associated with each open, so that setparams only
> affects the time returned to that opening process.  But this isn't
> explained either way, and I think it's because when RFC2783 was written
> the notion was that obviously only a single program like ntpd would do
> this for any given device.
> 
> From my skim of the Linux and NetBSD code, I think there's one pps state
> associated with the device, and that state is shared with all users.
> (But I read the code too fast.)

That was my read of the Linux code.  I'm assuming it's the offset
settings that drove the implementation to a shared set of parameters for
all applications that have the node open.

> This is important because if one process opens /dev/dty00 and sets an
> offset and does kcbind and another process opens /dev/dty00 and sets an
> offset, the kernel timekeeping can be affected.  I'm guessing this is
> the case you referred to above.  That's perhaps a case for having
> exclusive open when opening devices intended to control system time.

Yeah.


> > Yup.  It appears that working on serial device nodes appears to be a
> > choice the *BSDs made.  I suspect that Linux did not make that same
> > choice.
> 
> Agreed - this strikes me as odd because it requires an extra level of
> indirection for no apparent reason.

The reason in Linux appears to have been fear of anything mucking with
the fragile, high-entropy tty driver code base in the kernel.  (see link
below, Alan Cox was the tty system maintainer at the time.)

> > I base this on the existing gpsd code which divines the
> > correct /dev/pps? node, and on that Linux has a tty line discipline that
> > is explicitly used for setting up a /dev/pps? device that snoops the DCD
> > line of a tty. 
> 
> So basically some (beyond RFC2783) ioctl on the tty, which binds it to a
> /dev/ppsN and tells you which one?

gpsd actually has code that does this.

In ntpshm.c:init_kernel_pps():
 
        ioctl(session->gpsdata.gps_fd, TIOCSETD, &ldisc)

is called to set the line discipline to snoop DCD.

Then gpsd has to perform some rummaging in the Linux sysfs virtual file
system to find the /dev/pps? device node that gets created. :(


> Do the permissions from the tty get copied to the /dev/ppsN device?  (It
> seems obvious that one should be able to access /dev/ppsN iff one can
> access the underlying device.)

I do not know.

The end user can setup udev rules (hotplug device daemon rules) that set
user, group, permissions, symlinks, etc. on devices that appear in the
system.  Most users don't bother to set up special udev rules.


> >> Unless I'm missing something, in the docs I think we need to treat the
> >> notion of /dev/ppsN as Linux-specific.
> >
> > I think you are correct, but maybe the statement needs to be broader.
> >
> > Whatever the device node type and name, they have to be treated as OS
> > specific, since, as you mentioned, RFC2783 decided it was not in the
> > RFC's scope (Section 3.4.1).
> 
> Sure, that's fair.  But having it work on fds corresponding to serial
> ports is what a reader of RFC2783 applying the Principle of Least
> Astonishment would expect (imho). 

Agreed.  It is annoying on Linux that it does not. 


> Thanks for the discussion - now I understand the bigger picture.

> The remaining question is that I wonder why gpsd uses TIOCMIWAIT at all,
> given that time_pps_fetch() can be set to block until a sample appears.
> Is it a method for getting the timestamp in user space on Linux systems
> that have been compiled with support for checking DCD on a serial port
> but compiled without support for the RFC2783 interface?  If so,
> presumably that should be used only if RFC2783 support is missing.


TIOCMIWAIT existed in Linux in 1999 and perhaps earlier.

RFC2783 itself has a date of March 2000.

Linux support of RFC2783 came years later in 2008:
https://lkml.org/lkml/2008/9/13/44

Regards,
Andy