Hal Murray :
> So if you are saying that if the kernel has slew mode it has to call it
> ntp_adjtime or adjtime, that's OK, I guess, but not part of POSIX.
That is correct. I have researched this extensively, and while there are
still some places my grasp of the code is incomplete this is not on
>> POSIX defines ways to access the clock, but only the simple functions like
>> reading and setting the clock. It doesn't cover how to slew the clock or
>> tweak the clock speed (drift) - things like ntp_adjtime or adjtime(x).
> That is correct, but not relevant to the discussion of whether to
Hal Murray via devel :
>
> devel@ntpsec.org said:
> > I think C99 was used here to to include the whole NTPsec policy of also
> > wanting POSIX conformance. POSIX very much defines how the clock is played
> > with.
>
> POSIX defines ways to access the clock, but only the simple functions like
Gary E. Miller via devel :
> Yo Hal!
>
> On Fri, 15 Sep 2017 00:10:51 -0700
> Hal Murray via devel wrote:
>
> > [Subject says NetBSD, but context has drifted to MacOS]
> > > That said, I'm going to push - not hard, not hill-to-die-on, just
> > > moderately
> > > - for remaining strict about our
devel@ntpsec.org said:
> I think C99 was used here to to include the whole NTPsec policy of also
> wanting POSIX conformance. POSIX very much defines how the clock is played
> with.
POSIX defines ways to access the clock, but only the simple functions like
reading and setting the clock. It do
Yo Hal!
On Fri, 15 Sep 2017 00:10:51 -0700
Hal Murray via devel wrote:
> [Subject says NetBSD, but context has drifted to MacOS]
> > That said, I'm going to push - not hard, not hill-to-die-on, just
> > moderately
> > - for remaining strict about our C99 conformance policy and culling
> > old re
Hal Murray :
>
> [Subject says NetBSD, but context has drifted to MacOS]
> > That said, I'm going to push - not hard, not hill-to-die-on, just moderately
> > - for remaining strict about our C99 conformance policy and culling old
> > releases/minor platforms that can't meet it.
>
> We aren't dis
On 09/14/2017 11:46 PM, Eric S. Raymond via devel wrote:
A fair point. But...on the other hand, a major platform. Not by our
criterion, which is more or less "Are flocks of these going to be
running in $J_RANDOM_HUMONGOUS_DATACENTER?" Part of our strategy is
to optimize for the toughest, hig
[Subject says NetBSD, but context has drifted to MacOS]
> That said, I'm going to push - not hard, not hill-to-die-on, just moderately
> - for remaining strict about our C99 conformance policy and culling old
> releases/minor platforms that can't meet it.
We aren't discussing C99 but rather the
>> In an earlier post, Mark stated that he preferred to keep NetBSD6 support
>> if possible because it's still recent enough to get security fixes. If
>> the same criterion is applied to OSX, then 10.10 and 10.11 should be
>> supported.
>I'm absolutely going to count you as a senior dev. So, you
Fred Wright via devel :
>
> On Thu, 14 Sep 2017, Eric S. Raymond wrote:
>
> > So, did I make an ignorant mistake? Can this fix be rescued? Is
> > someone else better equipped than me for the rescue? (Translation:
> > I'd really love to dump this mess on Fred or Gary.)
>
> The point I was tryi
On Thu, 14 Sep 2017, Eric S. Raymond wrote:
> So, did I make an ignorant mistake? Can this fix be rescued? Is
> someone else better equipped than me for the rescue? (Translation:
> I'd really love to dump this mess on Fred or Gary.)
The point I was trying to make is that C doesn't promise tha
Yo Eric!
On Thu, 14 Sep 2017 21:26:46 -0400
"Eric S. Raymond via devel" wrote:
> Fred Wright via devel :
> > IMO, if a proper cost-benefit analysis of the use of long doubles
> > in the NTP context were conducted, it would result in a resounding
> > thumbs down.
> Best to avoid any doubt
Fred Wright via devel :
> IMO, if a proper cost-benefit analysis of the use of long doubles in the
> NTP context were conducted, it would result in a resounding thumbs down.
Thank you, Fred. I found your contribution measured and valuable even
though I'm not certain I understood all of the issues
On Wed, 13 Sep 2017, Hal Murray via devel wrote:
> I think the whole doubletime_t was a wild goose chase.
>
> The claimed reason was precision. A double has 53 bits. We are interrested
> in adjustments, not absolute values. If we are taking a huge adjustment (31
> bits), that still leaves 20 b
Gary E. Miller via devel :
> Yo Mark!
>
> On Thu, 14 Sep 2017 18:55:18 +
> Mark Atwood wrote:
>
> > Fair enough. We should still feed a bug report to NetBSD6, maybe one
> > of their FP guys will patch it in. And we drop NetBSD6 now, because
> > of that lack.
>
> Done. Awaiting the issue
Mark Atwood :
> Fair enough. We should still feed a bug report to NetBSD6, maybe one of
> their FP guys will patch it in. And we drop NetBSD6 now, because of that
> lack.
Checking...Matt already did the NetBSD 6 drop.
Any volunteer to file the NetBSD bug? I don't know their procedures.
--
Yo All!
> Done. Awaiting the issue number.
Just in:
Thank you very much for your problem report.
It has the internal identification `lib/52541'.
The individual assigned to look at your
report is: lib-bug-people.
>Category: lib
>Responsible:lib-bug-people
Yo Mark!
On Thu, 14 Sep 2017 18:55:18 +
Mark Atwood wrote:
> Fair enough. We should still feed a bug report to NetBSD6, maybe one
> of their FP guys will patch it in. And we drop NetBSD6 now, because
> of that lack.
Done. Awaiting the issue number.
RGDS
GARY
---
Fair enough. We should still feed a bug report to NetBSD6, maybe one of
their FP guys will patch it in. And we drop NetBSD6 now, because of that
lack.
..m
On Wed, Sep 13, 2017 at 5:52 PM Eric S. Raymond via devel
wrote:
> Gary E. Miller via devel :
> > Yo Mark!
> >
> > On Wed, 13 Sep 2017 23:
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
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
> 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
Yo Hal!
On Thu, 07 Sep 2017 20:09:44 -0700
Hal Murray wrote:
> > No, NTP doesn't do anything interesting here. The code predates
> > the era whend long double was standardized and generally available,
> > a transition that might have been as late as C99.
>
> So it seems reasonable to assume
Yo Hal!
On Thu, 07 Sep 2017 16:23:04 -0700
Hal Murray wrote:
> [Using ldexp when ldexpl isn't available.]
> > Serious loss of precision, but maybe the best we can do.
>
> Does anybody have any data on how serious that would be?
Yes, a float is 56 bits of precision. a timespec is 64 bits.
>
Matthew Selsky via devel :
> ldexpl() was added in NetBSD 7 (released Sept 2015). NetBSD 6 was released in
> Oct 2012 and last had a point release in Sept 2014). NetBSD 6 is still
> supported by upstream per https://www.netbsd.org/releases/formal.html#history
>
> NetBSD 8 is in beta and no relea
On Thu, Sep 07, 2017 at 12:47:42PM -0700, Gary E. Miller via devel wrote:
> Yo Hal!
>
> On Thu, 07 Sep 2017 01:37:30 -0700
> Hal Murray wrote:
>
> > > Got a workaround?
> >
> > This seems to build and check:
> > #include/* ldexpl() */
> > #ifndef ldexpl
> > /* Missing in NetBSD 6.1
> No, NTP doesn't do anything interesting here. The code predates the era
> whend long double was standardized and generally available, a transition
> that might have been as late as C99.
So it seems reasonable to assume that it's OK to run without the extra
precision.
The case I was worried
Hal Murray via devel :
>
> [Using ldexp when ldexpl isn't available.]
> > Serious loss of precision, but maybe the best we can do.
>
> Does anybody have any data on how serious that would be?
>
> Does ntp classic do anything interesting in this area? (That's the sort of
> thing that Dave Mills
[Using ldexp when ldexpl isn't available.]
> Serious loss of precision, but maybe the best we can do.
Does anybody have any data on how serious that would be?
Does ntp classic do anything interesting in this area? (That's the sort of
thing that Dave Mills is likely to have thought about.)
Did
On 9/7/17 12:55, Gary E. Miller via devel wrote:> Yes, and it must be.
The load on the server from that page is large,
more than a few users overloads the server.
But it is the only real time and accurate way to know what is working.
That's fine of course, it's simply that it was offered in an
Yo Paul!
On Thu, 7 Sep 2017 12:51:07 -0700
Paul Theodoropoulos via devel wrote:
> On 9/7/17 12:47, Gary E. Miller via devel wrote:
>
> >> Eric: Do we have a list of OSes and hardware where ntpsec is known
> >> to build and work?
> >
> > buildbot.ntpsec.org.
>
> Just fyi, that page is htp
On 9/7/17 12:47, Gary E. Miller via devel wrote:
Eric: Do we have a list of OSes and hardware where ntpsec is known
to build and work?
buildbot.ntpsec.org.
Just fyi, that page is htpasswd protected.
--
Paul Theodoropoulos
www.anastrophe.com
___
d
Yo Hal!
On Thu, 07 Sep 2017 01:37:30 -0700
Hal Murray wrote:
> > Got a workaround?
>
> This seems to build and check:
> #include/* ldexpl() */
> #ifndef ldexpl
> /* Missing in NetBSD 6.1.5 */
> #define ldexpl ldexp
> #endif
>
> Will that do the right conversions between double a
devel@ntpsec.org said:
> ldexpl() is POSIX 2008 and ISO/IEC 9899:1999 (a.k.a. C99). =20
> Not supporting C99 is pretty lame. NTPsec specifically requires C99
> support.
> So clearly a NetBSD problem.
Thanks.
Looks like they tried but didn't get everything. The man page says:
The descri
Yo Hal!
On Wed, 06 Sep 2017 15:23:13 -0700
Hal Murray via devel wrote:
> ../../include/ntp_fp.h:144:2: warning: implicit declaration of
> function 'ldexpl'
ldexpl() is POSIX 2008 and ISO/IEC 9899:1999 (a.k.a. C99).
Not supporting C99 is pretty lame. NTPsec specifically requires C99
support.
43 matches
Mail list logo
