Yo Hal!
On Sun, 26 Feb 2017 17:05:04 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > I thought we had killed it. If not it needs to be killed. It
> > should never be used.
>
> No.
>
> If nothing else, we need a way to test it to show that it is/isn't as
> good as other approaches.
No
g...@rellim.com said:
> I thought we had killed it. If not it needs to be killed. It should never
> be used.
No.
If nothing else, we need a way to test it to show that it is/isn't as good as
other approaches.
--
These are my opinions. I hate spam.
_
Mark: heads up! Policy issue.
Gary E. Miller :
> > No, it's still here, if you mean hardpps amd RFC1589 support. Though
> > I didn't know that until today - it's amost completely undocumented,
> > you have notice the hint dropped by the meaning of flag3 and then read
> > source code to get any i
Yo Eric!
On Sun, 26 Feb 2017 17:08:15 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > I thought we had killed it. If not it needs to be killed. It
> > should never be used.
>
> No, it's still here, if you mean hardpps amd RFC1589 support. Though
> I didn't know that until today - it'
Gary E. Miller :
> I thought we had killed it. If not it needs to be killed. It should never
> be used.
No, it's still here, if you mean hardpps amd RFC1589 support. Though
I didn't know that until today - it's amost completely undocumented,
you have notice the hint dropped by the meaning of fl
Gary E. Miller writes:
> Oh, that interface. NTP does not use that interface at all. If you are
> going to connect your PPS directly to the kernel then you do not use ntpd
> at all.
Yes it does, if you tell it to. But it won't on tickless kernels
whether you tell it or not since the kernel does
Achim Gratz writes:
> Yes. They should be functionally equivalent, yet still have different
> API.
I've looked, and indeed the hardpps function and the pps_kc_* functions
on Linux call the same implementation (__hardpps) in the end, so they're
functionally equivalent.
Regards,
Achim.
--
+<[Q+
Yo Fred!
On Sun, 26 Feb 2017 13:13:31 -0800 (PST)
Fred Wright wrote:
> > Oh, that interface. NTP does not use that interface at all. If
> > you are going to connect your PPS directly to the kernel then you
> > do not use ntpd at all.
>
> It can be enabled via some flags bits in ntp.conf (II
Yo Achim!
On Sun, 26 Feb 2017 22:12:59 +0100
Achim Gratz wrote:
> Gary E. Miller writes:
> > I do not see anything in that file I disagree with. Can you be more
> > specific on what you dislike in there?
>
> It shouldn't mention a kernel driver that doesn't exist anymore. PPS
> API is now a
On Sun, 26 Feb 2017, Gary E. Miller wrote:
> On Sun, 26 Feb 2017 12:42:37 -0800 (PST)
> Fred Wright wrote:
[...]
> > From drivers/pps/Kconfig:
> >
> > -
> > config NTP_PPS
[...]
> Oh, that interface. NTP does not use that interf
Gary E. Miller writes:
> I do not see anything in that file I disagree with. Can you be more
> specific on what you dislike in there?
It shouldn't mention a kernel driver that doesn't exist anymore. PPS
API is now available in mainline and that code is from the LinuxPPS
project.
>> It should pr
Yo Fred!
On Sun, 26 Feb 2017 12:42:37 -0800 (PST)
Fred Wright wrote:
> On Sun, 26 Feb 2017, Gary E. Miller wrote:
> > On Sun, 26 Feb 2017 14:29:59 +0100
> > Achim Gratz wrote:
> >
> > > It should probably be mentioned that hardpps is not available even
> > > with the PPS API present on most d
On Sun, 26 Feb 2017, Gary E. Miller wrote:
> On Sun, 26 Feb 2017 14:29:59 +0100
> Achim Gratz wrote:
>
> > It should probably be mentioned that hardpps is not available even
> > with the PPS API present on most distributions since it is
> > incompatible with a tickless kernel, something that bec
Yo Achim!
On Sun, 26 Feb 2017 13:58:36 +0100
Achim Gratz wrote:
> That list of definitions already exists since at least the year 2000,
> so maybe you'll read up on it there:
> https://www.ijs.si/time/
Interesting, but a bit dated and I do not totally agree with their
definitions. Nor do many
Yo Achim!
On Sun, 26 Feb 2017 14:29:59 +0100
Achim Gratz wrote:
> The kernel PPS documentation in docs/kernpps.txt still mentions
> PPSkit as the PPS API provider on Linux. PPSkit has not seen a
> release since 2007 and was replaced with the integration of LinuxPPS
> into the mainline kernel so
Yo Achim!
On Sun, 26 Feb 2017 17:56:51 +0100
Achim Gratz wrote:
> I'd like to ask for this driver to be retained until it's eventually
> replaced by matching functionality in the generic parse driver
> framework. It may well be that gpsd is technically superior, but the
> additional hassle of s
I'd like to ask for this driver to be retained until it's eventually
replaced by matching functionality in the generic parse driver
framework. It may well be that gpsd is technically superior, but the
additional hassle of setting things up for it counts against it. Also
it can't be assumed that
Eric S. Raymond writes:
> I just grepped for hardpps and found a world of previously
> undocumented complications.
>
> By 'hardpps' do you mean the RFC1589 facility?
Yes, that's what the RFC1589 implementation is called on Linux, based on
the API function. That interface was created _after_ the R
Achim Gratz :
>
> The kernel PPS documentation in docs/kernpps.txt still mentions PPSkit as
> the PPS API provider on Linux. PPSkit has not seen a release since 2007
> and was replaced with the integration of LinuxPPS into the mainline
> kernel somewhere in 2009.
OK, I can delete the text about
The kernel PPS documentation in docs/kernpps.txt still mentions PPSkit as
the PPS API provider on Linux. PPSkit has not seen a release since 2007
and was replaced with the integration of LinuxPPS into the mainline
kernel somewhere in 2009.
It should probably be mentioned that hardpps is not avai
Gary E. Miller writes:
> And before we can continue, for clarity, I'm going to try to define a
> few terms. Given the terminology swamp that is NTP, do not try too
> hard to apply this to the same words defined and used differently by
> NTP. Even worse NTP is not self consistent. Context is eve
21 matches
Mail list logo
