[LinuxPPS] [RFC] time_pps_createbyname()

[Rodolfo Giometti]

On Sun, Aug 05, 2007 at 04:19:50PM +0200, Frank Kardel wrote:
> Hello Rudolfo !
>
> Thanks for your work providing a PPS source for Linux.

:)

> I have been looking quite a while into LinuxPPS and it's integration
> into ntpd.
>
> I see that integrating LinuxPPS into ntpd requires source modification
> of quite a few drivers in ntpd. This is caused by a non-standard
> way of implementing the PPSAPI (RFC2783). The motivation for this

Yes.

> is, as I understand, the wish to support more PPS capable devices that do
> not necessarily have a PPSAPI implementation. While this is an

This is not correct. The goal is to support PPS sources which are not
connected with any char device at all.

In most embedded systems GPS antenna is connected with serial port but
PPS source is not. So in this case I have _no_ file descriptor to pass
to function time_pps_create().

> understandable goal it causes many headaches wrt/ ntpd integration.
> The main headaches are:
>  - supporting a different version of PPSAPI in PPSAPI capable
>    refclocks.
>  - naming - there is still the need to configure the right sources and
>    ntpd configuration system is, while still improving, very limited
>    there. Much of the configuration magic is done by accessing well
>    known file names.

I see, and IMHO this is the problem. NTP should consider that GPS data
and PPS data may came from different sources (even if from the same
physical device)!

> I believe the changing the PPSAPI causes more grief than it does good.

I completely agree with you but how can I solve the above problem with
the current PPSAPI? :)

> LinuxPPS already has everything there to support a standard PPSAPI 
> implementation
> without the need to deviate from the other PPSAPI implementations.

Again I agree with you but still I don't understand how I can solve my
problem. Let me do an example: some embedded systems have GPS antenna
connected with /dev/ttyS0 but PPS source is not connected with the
relative DCD pin but with a generic CPU's GPIO pin. In this case I
cannot supply serial port file descriptor to time_pps_create() and I
have no device to use in place of the serial port.

I think PPSAPI should separate GPS data devices from PPS data ones. So
instead of doing like this:

	fd = open("/dev/ttyS0", ...);

	time_pps_create(fd, &handle);

we should do:

	fd_gps = open("/dev/ttyS0", ...);

	fd_pps = open("/dev/pps0", ...);

using a simple file descriptor as PPS source's handler.

> Just three things are needed to get things working without much headaches:
>  - revert the PPSAPI implementation back to a clean file based one. (yes I 
> read your FAQs - read on)
>  - IMPORTANT: use the files listed via SYSFS and add the PPSAPI to these 
> files - gives you instant
>    file based PPSAPI via LinuxPPS which ntpd can use directly. Thus the pps 
> sources show up as PPSAPI
>    capable files in SYSFS.

I'm not sure to well understand what you mean. Are you saying that I
should use sysfs files to exachange PPS data between kernel and
userland? :-o

>  - change refclock drivers to allow for a separate PPSAPI capable file
>    (PARSE already does this /dev/refclock-? and /dev/refclockpps-? for 
> PPSAPI,
>      ATOM would work out of the box).
>
> This way
>    - ATOM can ve used without any patch.
>    - PARSE works out of the box and the other
>    - refclock drivers can grow separate PPS device files which benefits 
> them
>      in other PPSAPI environments also.
>    - number of separate patches for ntpd can be reduced (along with 
> maintenance
>      burden) to zero when all PPSAPI refclocks can make use of an
>      alternate PPSAPI file
>    - special casing in ntpd is removed.
>    - chances of integration increase because ntpd can be used out of the 
> box and
>      ntpd can use LinuxPPS out of th box too.

I think I have to review NTP code since I don't well understand your
solution! :)

What is "PARSE"? Is it a new NTP feature? Can you please give some
links where I can study it?

> I think this proposal can reduce the many headaches and delivers more 
> benefits than
> just clumsily supporting another non-standard PPS source.
>
> The more we can keep special casing out of ntpd the better it is - the ntp 
> development
> team just can not support every interface idea out there - thats why PPSAPI 
> was created.
> We where entangled in roughly 4 different PPS capable PPS interfaces - it 
> was no
> fun to maintain that.

I agree, but please, consider if current PPSAPI resolves my problem.

Thanks a lot for your suggestions and time!

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127