[LinuxPPS] [RFC] time_pps_createbyname()
Rodolfo Giometti
giometti at enneenne.com
Mon Aug 6 11:32:04 CEST 2007
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
More information about the LinuxPPS
mailing list