[LinuxPPS] 17Jun Patch

[Cirilo Bernardo]

On Wed, Jun 18, 2008 at 4:27 AM,  <clemens at dwf.com> wrote:
>
>> 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.
>

Yes, but it doesn't really matter whether the input/output is binary,
ascii or whatever; it is irrelevant to the PPS implementation.

> And there is the PPS timestamps from the device that give us an accurate time.
>
Yes, and the timestamp is created when an interrupt is received.  For
convenience people have been using the DCD pin on the serial ports,
but using a serial port's interrupt is not a requirement.  However,
since it is often convenient, people DO use the serial port DCD - if
they didn't then LinuxPPS would not need the PPS ldisc at all.

> 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.
>

(1) is already implemented - it is the ppsN device and it is
read-only.  I can't remember now if the device accepts IOCTLs since it
has been half a year since I looked at the code.

(2) that is the serial port device - and the read/write of data should
happen whether the ldisc is N_TTY or the PPS ldisc.  The use of the
PPS ldisc **may** interfere with some uses of the serial port - for
example, you cannot connect a modem while using the DCD for PPS.
Aside from the fact that the modem typically uses DCD for its own
operation, the modem will probably be operated by 'pppd' which will
change the ldisc to N_PPP which in turn makes PPS inoperative.

(3) The "somehow sees" is the PPS ldisc.   You can think of the line
discipline as a filter applied to the incoming and outgoing data
stream.  For example, with N_TTY you can switch off all filters (raw
mode), you can turn on software handshaking, and you can activate
character translations.  Ideally, the PPS ldisc will behave exactly
like N_TTY except that when it sees a change in DCD it gets a
timestamp and sends a notification to the pps core.  An additional
constraint is that the device using the serial port may not use DCD.

> 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.
>
(1) No, that is /dev/ppsN and it has nothing to do with line disciplines

(2) No, for the PPS to work as currently designed, this must be N_PPS.
 However, for all practical purposes, it behaves like N_TTY.

(3) This is the purpose of N_PPS which makes it a specialized form of N_TTY.

> 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.
>

In the older LinuxPPS code, the serial port could remain as N_TTY.
The kernel maintainers did not like the patches and suggested that a
line discipline should be used instead.  So Rodolfo changed the code
as suggested and implemented N_PPS.  The serial port cannot be
attached to both N_TTY and N_PPS - that is a fundamental limitation of
the design and really has nothing whatsoever to do with LinuxPPS.

(when finished and debugged) The new system with N_PPS will be 100%
like the older code with N_TTY, except that software which actually
queries the ldisc might get a bit confused because it has no idea what
N_PPS is (but such software is extremely rare).  The fundamental
restrictions are exactly the same in both cases - you can't run other
software/hardware (such as a modem and pppd) when your GPS is using
DCD for the PPS.

- Cirilo