[LinuxPPS] [RFC] time_pps_createbyname()

[Rodolfo Giometti]

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? :)

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.

Do you agree?

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