Harlan Stenn wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from withi
n
David Taylor wrote:
On 17/12/2014 08:52, Martin Burnicki wrote:
[]
This is just a subset of the information you get from ntpq -c rv, e.g.:
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86,
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs
Martin Burnicki martin.burni...@meinberg.de wrote:
Without having looked at the code base, I'm sure there are already
predefined macros available for the current build target/architecture.
So it should not be a problem to include something like
#if defined( SOLARIS )
#include
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
Without having looked at the code base, I'm sure there are already
predefined macros available for the current build target/architecture.
So it should not be a problem to include something like
#if defined( SOLARIS )
#include
Rob wrote: Martin Burnicki wrote:
Without having looked at the code base, I'm sure there are already
predefined macros available for the current build target/architecture.
So it should not be a problem to include something like
#if defined( SOLARIS )
#include timepps_solaris.h
#elif
E-Mail Sent to this address will be added to the BlackLists writes:
Somebody wrote:
So it should not be a problem to include something like
...
#elif defined ( LINUX ) || defined( FREEBSD )
#include timepps.h
#endif
Why would FREEBSD be included in that clause? FreeBSD comes with
On 12/18/2014 4:01 PM, Harlan Stenn wrote: E-Mail Sent to this address will be
added to the BlackLists writes:
Somebody wrote:
So it should not be a problem to include something like
...
#elif defined ( LINUX ) || defined( FREEBSD )
#include timepps.h
#endif
Why would FREEBSD be
On 2014-12-19, Harlan Stenn st...@ntp.org wrote:
That file is OK as GPL2. If it is ever upgraded and goes to GPL3, it
will be *removed* from the distribution if it does not include a license
exception.
Since I believe Linux has said that the kernel will always remain GPL2.x
it would seem
On Thu, Dec 18, 2014 at 7:42 PM, E-Mail Sent to this address will be added
to the BlackLists Null@blacklist.anitech-systems.invalid wrote:
... didn't someone just say licenses were not an issue,
when I pointed out they might be in a previous post ;-p
Yes, the current license isn't why the
Phil W Lee wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid considered Tue,
16 Dec 2014 14:26:49 + the perfect time to write:
It would be helpful if the output from ntpq -crv showed the OS on which
NTP was running, as well as the OS on which it was built. I've
mentioned this
David Taylor writes:
On 16/12/2014 13:48, Martin Burnicki wrote:
William Unruh wrote:
[]
And since at build time, one has things called configure which CAN run
tests on the build system, one could easily enable or disable it then.
But since as we all know ntpd tends to built on one
Martin Burnicki writes:
This is just a subset of the information you get from ntpq -c rv, e.g.:
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86, system=Windows, leap=00, stratum=2,
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or directly? Several refclock drivers do so.
You'll
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or directly? Several refclock drivers
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or
On 17/12/2014 08:52, Martin Burnicki wrote:
[]
This is just a subset of the information you get from ntpq -c rv, e.g.:
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86, system=Windows, leap=00,
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from withi
n
ntpd,
Harlan Stenn wrote:
Rob writes:
The file is only used at build time. It tells absolutely nothing
about the kernel configuration, certainly not in the system the binary
is running on.
You and I have completely different understandings about how APIs work
and what this header file is used for.
On Tue, Dec 16, 2014 at 8:52 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
In the past there may have been reasons to check this at compile time, but
as I've already pointed out in another posting the checks could at least be
made at runtime on system which likely provide a PPS API
On Mon, Dec 15, 2014 at 10:45 PM, E-Mail Sent to this address will be added
to the BlackLists Null@blacklist.anitech-systems.invalid wrote:
I would have guessed its more likely a timepps.h
License term issue? Perhaps timepps.h GNU General Public
Licensing has never come up in the various
On Tue, Dec 16, 2014 at 8:46 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
I'm not familiar with the PPS API provided by {SCO,Solaris,SunOS}. The
header files have to match the implemented API, and at least the API
supported by current Linux systems should be conforming to the RFC
On 16/12/2014 13:48, Martin Burnicki wrote:
William Unruh wrote:
[]
And since at build time, one has things called configure which CAN run
tests on the build system, one could easily enable or disable it then.
But since as we all know ntpd tends to built on one system and used on
myriads of
Paul wrote:
On Tue, Dec 16, 2014 at 8:52 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
In the past there may have been reasons to check this at compile time, but
as I've already pointed out in another posting the checks could at least be
made at runtime on system which likely provide
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or directly? Several refclock drivers do so.
You'll have to ask Harlan.
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Paul tik-...@bodosom.net wrote:
On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote:
You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES
ARE INCORRECT AS WELL!!
This is an example of what NTF doesn't want to deal
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Paul tik-...@bodosom.net wrote:
On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote:
You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES
ARE INCORRECT AS WELL!!
This is an example of what
While the following is not as applicable to the debian packaging
example, it's still on-point.
I'll also add that it's penny-wise and pound-foolish for us to take
patches that fix something for 1 specific case and have it break things
for anybody else.
The people who submit patches that are
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
--001a11c12566ef4fbd050a04ed7c
Content-Type: text/plain; charset=ISO-8859-1
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by
Paul tik-...@bodosom.net wrote:
On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote:
You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES
ARE INCORRECT AS WELL!!
This is an example of what NTF doesn't want to deal with. My instance of
Wheezy doesn't have
On Sun, Dec 14, 2014 at 4:56 AM, Rob nom...@example.com wrote:
gpsd can use pps without any kernel support and without any additional
files.
I didn't think we were talking about user-space solutions although
user-space PPS should be better than typical (bad) NMEA.
Rob writes:
Harlan Stenn st...@ntp.org wrote:
NTF will take it on after it gets funding for developers. I'd love to
see that happen sooner rather than later.
Oh come on... this is just a matter of copying one file of a few KB
into the include directory of the ntp package and you
Rob writes:
Paul tik-...@bodosom.net wrote:
On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote:
You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES
ARE INCORRECT AS WELL!!
This is an example of what NTF doesn't want to deal with. My instance of
Wheezy
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the
Harlan Stenn st...@ntp.org wrote:
Paul writes:
--001a11c12566ef4fbd050a04ed7c
Content-Type: text/plain; charset=ISO-8859-1
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API exists.
To repeat
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing
On Sat, Dec 13, 2014 at 5:01 AM, Rob nom...@example.com wrote:
Current build dependencies on Debian are:
That's better said on my install of Debian. I wouldn't expect it be the
case on all release tracks and it doesn't help Ubuntu.
Of course for an S1 operator the fact that this approach
Paul tik-...@bodosom.net wrote:
On Sat, Dec 13, 2014 at 5:01 AM, Rob nom...@example.com wrote:
Current build dependencies on Debian are:
That's better said on my install of Debian. I wouldn't expect it be the
case on all release tracks and it doesn't help Ubuntu.
Of course for an S1
On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote:
You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES
ARE INCORRECT AS WELL!!
This is an example of what NTF doesn't want to deal with. My instance of
Wheezy doesn't have ntp-dev.
Fortunately there is gpsd.
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
--001a11c12566ef4fbd050a04ed7c
Content-Type: text/plain; charset=ISO-8859-1
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the includefile does absolutely nothing in the ways of
solving
Sander Smeenk wrote:
Quoting Paul (tik-...@bodosom.net):
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not.
I was caught by the refclock strings that appear in the binary and the
--enable-all-clocks configure option being used. But the latter doesn't
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the includefile does absolutely nothing in the
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the header file is present we
expect it to do the right thing
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the header file is present
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
If I'm not mistaken (and it's getting late for me), if the header file
is missing we
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API exists.
To repeat what I reminded you of last time. Linux *doesn't* have the API.
The macros in timepps provide the RFC compliant API. The NTP
On 12/12/14 12:40, Martin Burnicki wrote:
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
NTP doesn't control this interface. The de
On Fri, Dec 12, 2014 at 9:47 AM, David Woolley
david@ex.djwhome.demon.invalid wrote:
NTP doesn't control this interface. The de facto interface is defined by
the kernel code.
I don't understand this.
___
questions mailing list
On 12/12/14 16:28, Paul wrote:
On Fri, Dec 12, 2014 at 9:47 AM, David Woolley
david@ex.djwhome.demon.invalid wrote:
NTP doesn't control this interface. The de facto interface is defined by
the kernel code.
I don't understand this.
My misunderstanding. I thought this was doing the job of
On 2014-12-12, Rob nom...@example.com wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The
Paul writes:
--001a11c12566ef4fbd050a04ed7c
Content-Type: text/plain; charset=ISO-8859-1
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API exists.
To repeat what I reminded you of last time.
Martin,
Martin Burnicki writes:
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
If I'm not mistaken (and it's getting late for
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
Martin,
...
It might very well be that we can separate some of these parts into an
internal and an external file, but again, we've been down this path
before with the MOD_NANO and STA_NANO stuff; why would we want to
*invite* this kind of
On Fri, Dec 12, 2014 at 7:23 PM, Harlan Stenn st...@ntp.org wrote:
In how many places should that be documented? Where should it be
documented in the NTP distribution, or on any of the websites?
Not to be (too) flip but I'd create a file called :README.1ST with some
text like:
Much of the
William Unruh writes:
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
Martin,
...
It might very well be that we can separate some of these parts into an
internal and an external file, but again, we've been down this path
before with the MOD_NANO and STA_NANO stuff; why would we want
Quoting Sander Smeenk (ssme...@freshdot.net):
1) Can i get a 'true PPS sync' with this setup?
2) What could i possibly do to get NTP to sync/accept the NMEA data,
Thanks for all tips about the other reference drivers and personal
experiences. I've got driver 20 (GENERIC_NMEA) running, but
On 2014-12-11 11:03, Paul wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not. Debian derived distos using upstream ntp don't have
PPS support. However it's fairly
Quoting Paul (tik-...@bodosom.net):
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not.
I was caught by the refclock strings that appear in the binary and the
--enable-all-clocks configure option being used. But the latter doesn't
actually mean all
A C agcarver+...@acarver.net wrote:
On 2014-12-11 11:03, Paul wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not. Debian derived distos using upstream ntp don't have
Paul tik-...@bodosom.net wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not. Debian derived distos using upstream ntp don't have
PPS support. However it's fairly
On 2014-12-11 12:33, Rob wrote:
A C agcarver+...@acarver.net wrote:
On 2014-12-11 11:03, Paul wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not. Debian derived distos
On Dec 11, 2014 2:55 PM, A C
Debian wheezy's packaged ntpd does include PPS support.
Given the Debian position on timepps this is surprising. Of course what
happens in Wheezy and BSD may not be relevant to Ubuntu users like the OP.
pps-tools is also available from launchpad if you're not
Quoting Rob (nom...@example.com):
Debian wheezy's packaged ntpd does include PPS support. I am currently
running ntpd from that stable repository and running the ATOM refclock
(22). The pps-tools package is also available in the repository for
direct installation.
That must be new.
A C agcarver+...@acarver.net wrote:
On 2014-12-11 12:33, Rob wrote:
A C agcarver+...@acarver.net wrote:
On 2014-12-11 11:03, Paul wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost
On 2014-12-11 13:46, Rob wrote:
A C agcarver+...@acarver.net wrote:
On 2014-12-11 12:33, Rob wrote:
A C agcarver+...@acarver.net wrote:
On 2014-12-11 11:03, Paul wrote:
On Thu, Dec 11, 2014 at 11:14 AM, Sander Smeenk ssme...@freshdot.net
wrote:
But i'm quite sure driver 22 is compiled in
On Thu, Dec 11, 2014 at 4:57 PM, Sander Smeenk ssme...@freshdot.net wrote:
Aparently all that is missing in the ntp package (in Ubuntu?) is a
Build-Depends on the pps-tools package to provide timepps.h in
/usr/include/sys/
This doesn't even introduce new binary dependencies. The pps-tools
Sander Smeenk ssme...@freshdot.net wrote:
Quoting Rob (nom...@example.com):
Debian wheezy's packaged ntpd does include PPS support. I am currently
running ntpd from that stable repository and running the ATOM refclock
(22). The pps-tools package is also available in the repository for
On 2014-12-11, Sander Smeenk ssme...@freshdot.net wrote:
Quoting Rob (nom...@example.com):
Debian wheezy's packaged ntpd does include PPS support. I am currently
running ntpd from that stable repository and running the ATOM refclock
(22). The pps-tools package is also available in the
William Unruh writes:
It is one of those pissing matches. Ntp thinks the os should provide
timepps.h, while the others think ntpd should provide it if they need
it. As a result the users get screwed while the self-righteous can
continute in glory. Just like with cdrecord.
Bullshit.
It's an
73 matches
Mail list logo
