linux-kernel - [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Mar 2007 08:41:21 +0100
From:	Rodolfo Giometti <giometti@...eenne.com>
To:	linux-kernel@...r.kernel.org
Cc:	linuxpps@...enneenne.com
Subject: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux

Pulse per Second (PPS) support for Linux.

Signed-off-by: Rodolfo Giometti <giometti@...eenne.com>

---

Please, note that this PPS implementation is not RFC 2783 fully
compatible since, IMHO, the RFC simply doesn't consider PPS devices
connected with special GPIOs or other ports different from serial
ports and parallele ports.

Please read the following consideratios before sending to /dev/null!
:)

RFC considerations
------------------

While implementing a PPS API as RFC 2783 defines and using an embedded
CPU GPIO-Pin as physical link to the signal, I encountered a deeper
problem:

   At startup it needs a file descriptor as argument for the function
   time_pps_create().

This implies that the source has a /dev/... entry. This assumption is
ok for the serial and parallel port, where you can do something
usefull beside(!) the gathering of timestamps as it is the central
task for a PPS-API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
precondition for the use of a PPS-API. On the other hands may happen
that a GPS antenna (which is also a PPS source) is connected to the
system throught a serial line but the PPS signal is not and it uses a
GPIOs, so we cannot consider the serial line as a PPS source at all!

The problem can be simply solved if you change the original RFC 2783:

    pps_handle_t type is an opaque __scalar type__ used to represent a
    PPS source within the API

into a modified:

   pps_handle_t type is an opaque __variable__ used to represent a PPS
   source within the API and programs should not access it directly to
   it due to its opacity.

This change seems to be neglibile because even the original RFC 2783
does not encourage programs to check (read: use) the pps_handle_t
variable before calling the time_pps_*() functions, since each
function should do this job internally.

If I intentionally separate the concept of "file descriptor" from the
concept of the "PPS source" I'm obliged to provide a solution to find
and register a PPS-source without using a file descriptor: it's done
by the functions time_pps_findsource() and time_pps_findpath() now.

According to this current NTPD drivers' code should be modified as
follows:

+#ifdef PPS_HAVE_FINDPATH
+      /* Get the PPS source's real name */
+      time_pps_readlink(link, LENPPS, path, PPS_MAX_NAME_LEN);
+
+      /* Try to find the source */
+      fd = time_pps_findpath(path, PPS_MAX_NAME_LEN, id, PPS_MAX_NAME_LEN);
+      if (fd < 0) {
+              msyslog(LOG_ERR, "refclock: cannot find PPS source \"%s\" in the system", path);
+              return 1;
+      }
+      msyslog(LOG_INFO, "refclock: found PPS source #%d \"%s\" on \"%s\"", fd, path, id);
+#endif   /* PPS_HAVE_FINDPATH */
+
+
       if (time_pps_create(fd, &pps_handle) < 0) {
-              pps_handle = 0;
               msyslog(LOG_ERR, "refclock: time_pps_create failed: %m");
       }

View attachment "ntp-pps-2.6.20.diff" of type "text/x-diff" (63917 bytes)