[LinuxPPS] [RFC] time_pps_createbyname()

[Frank Kardel]

Rodolfo Giometti wrote:
> 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.
>   
That's what I meant - no char device - no PPSAPI.
> 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().
>   
Yes - that's why I made the proposal.
>   
>> 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)!
>   
Some refclock drivers do just that. So you can do serial communication
via a
serial port and get PPS informat from, say, lpt0.
>   
>> 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? :)
>
>   
I hope I can clarify the mechanism further below.
>> 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", ...);
>   
Yes, you have the right idea.
> 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
>   
basically yes. You already have all information in linuxpps at one
place. Even the
gpio pins can register there. You are currently exporting PPSAPI
information via
sysfs. - so why not use that mechanism to implement the file based PPSAPI ?
Ideally you could provide a char device with the PPSAPI ioctls to access
PPSAPI information
information (benefits: reduces conversions, can hold state
(assert/clear/offsets)).
Or you could even read the ascii files and parse the information from
there - need more
conversions and is a bit difficult to handle wrt/ PPSAPI mode selection
as different modes
would currently refer to different files in your current model.

So things would get easy if you just provided a generic PPSAPI char
device for each
PPS-Source LinuxPPS knows.
>   
>>  - 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?
>
>   
PARSE is the PARSE reference clock (ntpd/refclock_parse.c) - driver 8.
Actually this is a multi clock driver supporting many different clocks and
PPS.

PARSE knows to handle two devices - one communication/pps device for the
setups where the communication device also can do PPSAPI. And - if it can be
opened - a PPS capable device - that is used for PPSAPI. This way PARSE
can easily handle both combinations: single communication/PPS device and
a communication device plus a separate PPS device.
Changing other refclocks to support that scheme is easy and gives
benefits in all
PPSAPI environments.
>> 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
>
>   

Happy researching PARSE... - it already implements (since 4.2.4) your
idea mentioned
about about opening two fds - one for communication and one for PPSAPI
(look for ppsfd).

Ciao,
  Frank