Yo All!
I have a provisional fix for issue #62:
https://gitlab.com/NTPsec/ntpsec/issues/62
In the NMEA refclock (#20), when PPS is lost, the peer jitter was left
at the low value calculated for PPS. This jitter is then used for NMEA.
So the NMEA time is wrongly thought to be PPS precise. This
Gary E. Miller via devel :
> Yo Mark!
>
> On Wed, 13 Sep 2017 23:15:10 +
> Mark Atwood wrote:
>
> > We could just grab from NetBSD7.
>
> Nope, that is very low level FPU assembly code. Very arch dependent.
> Usually buried deep in the C compiler as a builtin.
>
> Just look at gcc for all
(I'll be out for the next day or so, so don't expect prompt answers. Sorry
this isn't cleaner. Gotta run.)
There may be bogus stuff in here. Measure twice, edit once.
I think the whole doubletime_t was a wild goose chase.
The claimed reason was precision. A double has 53 bits. We are inter
Yo Mark!
On Wed, 13 Sep 2017 23:15:10 +
Mark Atwood wrote:
> We could just grab from NetBSD7.
Nope, that is very low level FPU assembly code. Very arch dependent.
Usually buried deep in the C compiler as a builtin.
Just look at gcc for all the arch options it has for floating point!
> Or
We could just grab from NetBSD7. Or if we know it's an IEEE754 float, just
do the direct bit ops. Or the direct fp cpu op.
..m
On Wed, Sep 13, 2017 at 4:05 PM Gary E. Miller via devel
wrote:
> Yo Mark!
>
> On Wed, 13 Sep 2017 22:31:31 +
> Mark Atwood via devel wrote:
>
> > How much compl
Yo Mark!
On Wed, 13 Sep 2017 22:31:31 +
Mark Atwood via devel wrote:
> How much complexity would it add to add the missing fp functions in
> the same way the strlcpy function is?
I think all we need for NetBSD 6.1 is ldexpl().
Here is one way, a very slow way, to do it:
long double ldexpl
How much complexity would it add to add the missing fp functions in the
same way the strlcpy function is?
It doesnt even have to be fully generic, just if NetBSD6 etc. If a BSD is
still supported by it's community, I'm not happy about dropping it.
..m
On Wed, Sep 13, 2017 at 1:17 PM Eric S. Ray
Mark Atwood via devel :
> NetBSD6 still supported, so it's still running in the wild.
>
> I know we've been removed most compatibility shims, but are they all gone?
> or do we still have a chunk of "if this OS, then define these missing
> functions"?
I think the last OS-related shim where we de
fallenpega...@gmail.com said:
> I know we've been removed most compatibility shims, but are they all gone?
> or do we still have a chunk of "if this OS, then define these missing
> functions"?
We have replacements for some non-POSIX string functions that are in many but
not all systems.
Ther
NetBSD6 still supported, so it's still running in the wild.
I know we've been removed most compatibility shims, but are they all gone?
or do we still have a chunk of "if this OS, then define these missing
functions"?
..m
On Wed, Sep 13, 2017 at 12:16 PM Hal Murray wrote:
>
> > Is NetBSD 6 st
Achim Gratz via devel writes:
> [resent and expanded, the original posting did not make it to Gmane NNTP]
The missing postings have belatedly appeared on Gmane now, so it seems
to have been a hiccup somewhere between the listserver and Gmane or on
Gmane itself.
Regards,
Achim.
--
+<[Q+ Matrix-1
> Is NetBSD 6 still under development?If so, we can send them a bugreport.
Development has moved on to 7 and soon to be 8.
6 is still supported which means security fixes get backported.
--
These are my opinions. I hate spam.
___
devel ma
I agree, drop NetBSD6 and document why.
Is NetBSD 6 still under development?If so, we can send them a bugreport.
On the other other hand, do we still have any other compatibility shims
anywhere else for any other OSes? floating point ops like this are
"merely" some simple bit twiddles, as l
13 matches
Mail list logo
