[LinuxPPS] [RFC] time_pps_createbyname()

[Frank Kardel]

> On Sun, Aug 05, 2007 at 11:34:10PM +0200, Frank Kardel wrote:
>> > Rodolfo Giometti wrote:
>> >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.
>
> Ok, having one PPS char device (/dev/ppsX) for each PPS source could
> be a good solution. However I think that, in this case, we just use an
> ioctl() interface to get/set data since I doubt that Linux's gurus
> will accept data exchange by sysfs. :)
>
>> 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.
>
> Ok, looking here:
>
>    http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html
>
> it seems that this driver uses both "/dev/refclock-u" and
> "/dev/refclockpps-u" devices, and looking at code it seems to me that
> for each PPS device PARSE does the following steps:
>
> 	ppsfd = open(parseppsdev, ...);
> 	if (ppsfd == -1)
> 	{
> 		ppsfd = fd232;
> 	}
>
> 	time_pps_create(ppsfd, &ppshandle);
>
> so in LinuxPPS we should do two symbolic links as follow:
>
> 	$ ln -s /dev/ttyS0 /dev/refclock-0
> 	$ ln -s	/dev/pps0 /dev/refclockpps-0
>
> and function time_pps_create() should simply do like this:
>
> 	*ppshandle = ppsfd;
>
> and everything should continue to work, is that right? :)
Yepp. Looks simple - doesn't it :-)

>
> If so I should change (again) LinuxPPS internals in order to implement
> each PPS sources as a char device mapped in /dev/ppsX. It will be up
> to the user doing correct mapping between
> "/dev/refclock-u"-"/dev/refclockpps-u" and
> "/dev/ttySX"-"/dev/ppsX". Than other refclocks should be changed in
> order to support the same concept as in PARSE refclock.
If I understand the previous poster wright the drivers may be
already doing the right thing. We just need to check and identify any missing
drivers.

>
> Do you agree?

Yes - you got the idea (which I hope will save us all much work).

I'd like the idea to have the PPS source by their name in sysfs.
It would be easier for the user to pick the right one instead of
having to figure out whether pps1 is ttyS0 or is it pps0 ? That would
again depend on configured devices and be prone to changes in the
environment. Maybe /dev/pps-<name><number> could work.

I don't know about the policies within Linux wrt/ sysfs, but maybe
a working PPS device is fine with them. After all, it would be the real
device anyway.

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

Ciao,
  Frank