[LinuxPPS] 17Jun Patch

[clemens at dwf.com]

> On Wed, Jun 18, 2008 at 12:44 AM,  <clemens at dwf.com> wrote:
> [snip]
> >>
> >> It looks right to me; the PPS virtual device is not a TTY so the IOCTL
> >> should fail.  It is the GPS device which should continue to function
> >> as a TTY and essentially be unaffected by the PPS line discipline.
> >>
> >> - Cirilo _______________________________________________
> >
> > The IOCTL in question is TIOCGETD which gets the type of the line discipline,
> > and there should be no failure in returning that value.
> >
> > I would expect the Serial device to be a serial device, nothing should have
> > changed there, and it should return "0" for N_TTY.
> > The new device /dev/pps1 should return 17 for N_PPS.
> >
> 
> I don't agree; line disciplines are associated with TTY devices.  A
> serial port can only be associated with one line discipline at a time,
> so when a port is used for a GPS device with the PPS ldisc you should
> expect the reported line discipline to be the one for PPS, not N_TTY.
> However, there is no reason that the PPS line discipline would not
> behave as N_TTY in all other respects.  

I can see where we differ now.
There are several streams of input and output from the device.
There is INPUT/OUTPUT from the PPSAPI function calls, (calls which are turned 
into IOCTLs) and pass information from the user to/from the kernel.  For this, 
some
function calls that map the PPSAPI to one or more ioctl's are added.

There is BINARY INPUT/OUTPUT data from the device (say the ONCORE receiver)
to/from the user, without this data we could not control the receiver or 
determine the time.

And there is the PPS timestamps from the device that give us an accurate time.

Would you break this up into three devices then?
    (1) a device that understands the PPSAPI protocol (to/from user/kernel)
    (2) a device that passes binary strings (to/from user/receiver)
    (3) a device that somehow sees the PPS pulses from the receiver and turns
         them into timestamps.

Other UNIX operating systems are able to do this on one device with no
problems.  I have never understood why THIS Linux implementation needed
two (or if you believe the above three) devices to do the same thing.

To my way of thinking, the above three devices would be
    (1) probably N_PPS
    (2) N_TTY
    (3) something else again.

Whatever you call things, there will be a device that is passing binary data 
from
the receiver to the user and I can see no reason why that device should be 
anything
but N_TTY.  For the current implementation this is /dev/ttyS0, which serves 
mostly
to pass binary data to/from the receiver and perhaps at the 1-2% level does 
the PPSAPI
passing data from the user to the kernel.

So I still think the device should be N_TTY.

-- 
                                        Reg.Clemens
                                        reg at dwf.com