[ntp:questions] Attn Linux distributors - pse include PPS
nomail at example.com
Sun Apr 27 13:11:51 UTC 2014
Jochen Bern <Jochen.Bern at LINworks.de> wrote:
> On -10.01.-28163 20:59, Rob wrote:
>> Apparently there is unresolved discussion whether a .h describing a
>> PPS API belongs in the set of kernel include files or in a separate
> There is? Can't say I've ever dealt with PPS, but *if* this .h provides
> the necessary information that *several* pieces of userland software
> need to use a kernel API, with the details/version of that API tied to
> the underlying kernel version and nothing else, then there should be
> only three kinds of package suitable to provide that .h:
> a) the kernel itself (i.e., always present),
> b) the package providing the kernel module providing the API (*if* made
> into a module for the distributed kernel), or
> c) a hypothetical "devel" package that provides the .h, but *not* some
> set of userland utilities on top unless they're strictly necessary
> (e.g., to "configure" the API in some way before it can be used).
I fully agree with that.
(I wondered why the .h file is in package pps-tools and not pps-tools-dev
or in the kernel include file set)
> Of course, if there's some history of this API's development that needs
> to be taken into account for compatibility reasons, things can get ...
> complicated. There's no such thing as 'if [ -f foo.h ]; then #include
> <foo.h> ; else #include "my_foo.h"' (post-./configure) ...
There apparently is some confusion whether timepps.h should be in
/usr/include or /usr/include/sys but the ./configure for ntpd already
>> But the separate package pps-tools which includes this file already
> I wonder whether we can take the package description:
> as an actual declaration of *intent* from Debian to keep the .h there.
LinuxPPS support tools and headers
This package includes the necessary headers for using LinuxPPS
PPSAPI kernel interface in user-space applications and several
* ppstest: PPSAPI interface tester
* ppsldisc: setup correct RS232 line discipline
* ppswatch: continuously print PPS timestamps
* ppsctl: PPS device manager
* ppsfind: find pps device by name
Apparently they realize that they have mixed up two things in one package.
But those tools are minute in size and will not disturb anything.
>> I don't understand why this is a problem that can be fixed in a minute.
>> There must be TENS of packages that have to be installed on the build
>> machine to successfully build the binaries in the distribution.
>> Compilers, linkers, packaging tools, libraries, etc etc etc.
>> Can't they add just one simple package to that?
> Well *there* you're confusing the software installed on it *to make it a
> build machine* and the packages installed so as to *get built*. Imagine
> cross-compiling being involved and you'll see how one needs to be kept
> separate from the other.
What I mean is that for building packages they need not only building
tools but also -dev packages for many libraries that are going to be
used by the packages being built. There is a long list of packages that
one is supposed to install before even attempting to build a single
package from source, and then the particular package adds more requirements.
This timepps.h file is just one tiny little file between many other
.h .a and .so files.
> I'd imagine that the folks dealing with embedded devices would have a
> couple choice words about forcing the entire pps-tools into *every*
> installation just so as to make the PPSAPI available, maybe even the IT
> security people (particularly if there's set[ug]id involved with them).
ls -l /usr/bin/pps*
-rwxr-xr-x 1 root root 10672 May 25 2012 /usr/bin/ppsctl
-rwxr-xr-x 1 root root 298 May 25 2012 /usr/bin/ppsfind
-rwxr-xr-x 1 root root 10352 May 25 2012 /usr/bin/ppstest
-rwxr-xr-x 1 root root 10576 May 25 2012 /usr/bin/ppswatch
I am not forcing anything upon embedded devices, it may even be that
those devices don't support the PPS API. I only suggest that the
file required to enable PPS support is installed on systems used for
building the binaries, so nptd will be compiled with PPS support in
environments where this is available.
Several years ago I wanted to sync my clock to a GPS providing PPS.
At that time, PPS support in the kernel was only available as a set
of patches. You had to apply them to a kernel source tree and rebuild
the kernel. And I think there were several competing patchsets.
You also needed to build a program that would actually bind the PPS
to a device pin.
Not wanting to go through all that trouble, I wrote the part of the
gpsd program that takes the PPS info in a userspace thread and puts
the information in an SHM segment that ntpd can use as a refclock.
Support for PPS without having to patch or recompile existing binaries.
This worked well, but lately I have been working on a project that has
more strict timing requirements and I investigated the current state
of things w.r.t kernel PPS.
PPS support has been incorporated in the kernel. Distributors compile
kernels with PPS support built in, and include modules for parallel,
serial and gpio ports. Things are looking good.
ntpd has support for this kernel PPS in its source tree. Availability
of PPS API is autodetected, and ntpd refclock drivers are using it.
Linux distributors compile ntpd with a (default) set of options that
basically says: please include all refclock drivers that are supported
on this system. Fine!
BUT STILL IT DOES NOT WORK
Why? Because a single file was missing during compilation.
And when I suggest to fix that, all kinds of reasons are popping up
why this isn't going to happen, isn't wanted, etc.
I think it is a big waste of effort made by many people who contributed
to what we now have. Pity.
More information about the questions