Code freeze
We're preparing for a minor point release, probably 1.17, on or about 1 Aug. Code freeze starts now. Bug fixes only, -- http://www.catb.org/~esr/";>Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Converted stat_count struct to a module level global. (!1026)
Merge Request !1026 was merged
The Subject says "Converted stat_count struct to a module level global"
The code looks like it is un-struct-ing things.
Was that "a module level global" supposed to be "module level globals"?
What's the policy on this area? I thought the general idea was to put things
into structs, but I never saw a good story on why that's a good idea.
Is the problem one of name space structure/clutter? If I'm reading the code,
there isn't any difference between foo.counter and foo_counter. The actual
names used are critical.
+extern uptime_t stat_stattime(void);
+extern uint64_t stat_received(void);
+extern uint64_t stat_processed(void);
...
-struct statistics_counters {
- uptime_tsys_stattime; /* time since sysstats reset */
- uint64_tsys_received; /* packets received */
- uint64_tsys_processed; /* packets for this host */
...
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Converted stat_count struct to a module level global. (!1026)
On 8/28/19 1:26 PM, Hal Murray wrote: Merge Request !1026 was merged The Subject says "Converted stat_count struct to a module level global" The code looks like it is un-struct-ing things. Was that "a module level global" supposed to be "module level globals"? !1026 moves the variables from a struct defined globally for the entire program to a struct defined globally within a single module (ntp_proto.c). Most usage of those fields is in that module, and almost all of the exceptions are reads in ntp_control. Now all access from outside of ntp_proto is done via functions. What's the policy on this area? I thought the general idea was to put things into structs, but I never saw a good story on why that's a good idea. The general idea is to remove as many globals as possible. The first pass of that process is to turn groups of associated global variables into structs that are defined at the same level as the original variables. Now I'm taking some of those structs and where possible reducing their footprint within the program, and insulating different modules in the possible. Is the problem one of name space structure/clutter? If I'm reading the code, there isn't any difference between foo.counter and foo_counter. The actual names used are critical. It is reducing unnecessary globals because globals are a good thing to reduce. Also it is preparation for the Go port. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Converted stat_count struct to a module level global. (!1026)
Thanks. Ahh... Part of the problem is that I misread the diffs. I didn't notice that the additions were procedures. I thought it was restoring the individual counters. ianbru...@gmail.com said: > It is reducing unnecessary globals because globals are a good thing to > reduce. In general, I agree that reducing globals is a good idea. It's not globals that are evil, it's the complexity they normally introduce. It's not clear that replacing a global with a procedure to read it reduces that complexity when the counter is a simple counter. > !1026 moves the variables from a struct defined globally for the entire > program to a struct defined globally within a single module (ntp_proto.c). > Most usage of those fields is in that module, and almost all of the > exceptions are reads in ntp_control. Now all access from outside of > ntp_proto is done via functions. If I was trying to clean up this area, I think the important step would be to move the API for those counters out of ntpd.h into a new header file. (Mostly, that's reducing clutter in ntpd.h. I may be more sensitive to clutter than other people.) Are counters an important enough concept that they deserve special treatement? -- This discussion reminds me that the counters for DNS and NTS can be bumped by various threads so they need a lock. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Converted stat_count struct to a module level global. (!1026)
Yo Hal! On Wed, 28 Aug 2019 12:56:33 -0700 Hal Murray via devel wrote: > ianbru...@gmail.com said: > > It is reducing unnecessary globals because globals are a good thing > > to reduce. > > In general, I agree that reducing globals is a good idea. It's not > globals that are evil, it's the complexity they normally introduce. > > It's not clear that replacing a global with a procedure to read it > reduces that complexity when the counter is a simple counter. So replacing a global variable name with a global function name. No win there. Plus the speed loss of calling a function for a simple task, load time link computations, etc. Possibly justified if some sort of locking or memory barrier is also paired with the counter functions. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpgMu56FQkqC.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: %m, #614
Gary E. Miller via devel writes: > I was not talking about strerror_r(). But this thread is about that exact function. > I was talking about strnXXX() > and struct ifreq. If you talk about strnlen, it's not used in ntpsec (current master). The other strnXXX functions are ANSI C and don't need a header or library (but you mostly shouldn't use them for other reasons of course). I note in passing that strncpy is used anyway in the json example code. The ifreq struct innards are OS specific, so you need a shim anyway if you must go in directly. But you shouldn't poke it like that and use the accessor macros from net/if.h instead (these already are in the XTI POSIX extension I believe and should be old enough to be covered by the POSIX version that ntpsec targets I'd think). The current Linux version of that doesn't need any feature test macros to activate those definitions, btw. It's entirely possible that other systems or older Linux versions did, especially when IPv6 support was new. Also, current Linux addresses this problem in a different manner, see linux/libc-compat.h (in other words, _GNU_SOURCE is no longer the actual guard for the struct members and you'll be much better off using a more specific feature test). That leaves the BSD jail functions that I know nothing about, but I'm dubious about these needing _GNU_SOURCE. THey may become visible as a side effect of _GNU_SOURCE, but again there should be a more specific feature test. > Not at all what I meant. Flexible about what NTPsec builds on, not > flexible about the end result. You were arguing for defining _GNU_SOURCE, were you not? >> You already try to use both > > Uh, not me white man Not my code. That is relevant to the discussion how? > Yes, Hal is the one working on it. James also did a lot of work on > strerror_r(). I'm just staying out of their way. Yet you keep arguing that _GNU_SOURCE should or could be defined, which is the source of the problems in issue #614. You can't be POSIX compatible and define _GNU_SOURCE at the same time (and that already assumes that the system libc either is a sufficiently modern glibc version or some other library that took some pains to emulate glibc quirks to provide portability for ATWIL[*] programs). [*] All the world is Linux. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Eric, there is a incompatibility break, so could we do 1.2.0 , please? -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane On Thu, Aug 29, 2019 at 1:47 AM Eric S. Raymond via devel wrote: > We're preparing for a minor point release, probably 1.17, on or about > 1 Aug. > > Code freeze starts now. Bug fixes only, > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > "...The Bill of Rights is a literal and absolute document. The First > Amendment doesn't say you have a right to speak out unless the > government has a 'compelling interest' in censoring the Internet. The > Second Amendment doesn't say you have the right to keep and bear arms > until some madman plants a bomb. The Fourth Amendment doesn't say you > have the right to be secure from search and seizure unless some FBI > agent thinks you fit the profile of a terrorist. The government has no > right to interfere with any of these freedoms under any circumstances." > -- Harry Browne, 1996 USA presidential candidate, Libertarian Party > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Sanjeev Gupta : > Eric, there is a incompatibility break, so could we do 1.2.0 , please? Mark's call. I beliecew he's considering shipping 1.2.0 shortly after. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Yo Sanjeev! On Thu, 29 Aug 2019 07:15:56 +0800 Sanjeev Gupta via devel wrote: > Eric, there is a incompatibility break, so could we do 1.2.0 , please? What is the break? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpcojjDzPJa9.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: %m, #614
Yo Achim! On Wed, 28 Aug 2019 22:17:43 +0200 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > I was not talking about strerror_r(). > > But this thread is about that exact function. We'll have to disagree there. I feel it is much more generic to the defines that pull in stuff. > > Not at all what I meant. Flexible about what NTPsec builds on, not > > flexible about the end result. > > You were arguing for defining _GNU_SOURCE, were you not? Nope. > >> You already try to use both > > > > Uh, not me white man Not my code. > > That is relevant to the discussion how? We agree on that! > > Yes, Hal is the one working on it. James also did a lot of work on > > strerror_r(). I'm just staying out of their way. > > Yet you keep arguing that _GNU_SOURCE should or could be defined, Uh, no. I'm not sure who you are arguing with on that. I'm just reminding folks of things recently learned on gpsd about the feature macro thing. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp5mzEUaq5mJ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
On Wed, Aug 28, 2019 at 5:24 PM Eric S. Raymond via devel wrote: > Sanjeev Gupta : > > Eric, there is a incompatibility break, so could we do 1.2.0 , please? > > Mark's call. I beliecew he's considering shipping 1.2.0 shortly after. My impression is that he is waiting for the IETF and IANA to handwave the NTS draft 20 into a proper RFC. BTW IIUC passing google-readability-braces-around-statements to clang-tidy gets more of those pesky corner cases. There is a section in libntp/clockwork.c that needs some attention afterwards though. There are probably more I do not see. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Gary, ALPN string checking. The commit mentioned that it would break with previous NTPSec versions. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane On Thu, Aug 29, 2019 at 8:28 AM Gary E. Miller via devel wrote: > Yo Sanjeev! > > On Thu, 29 Aug 2019 07:15:56 +0800 > Sanjeev Gupta via devel wrote: > > > Eric, there is a incompatibility break, so could we do 1.2.0 , please? > > What is the break? > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can't measure it, you can't improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Sanjeev Gupta said: > Gary, ALPN string checking. The commit mentioned that it would break with > previous NTPSec versions. No. The client didn't check the returned ALPN string. It didn't even look to see if there was a returned ALPN string. I added that checking recently. It doesn't bail on mismatch, just logs things. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Code freeze
Sanjeev Gupta via devel writes: > Gary, ALPN string checking. The commit mentioned that it would break > with previous NTPSec versions. But it doesn't, because the returned protocol was not checked. Otherwise it would have never worked in the first place. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: %m, #614
Gary E. Miller via devel writes: >> But this thread is about that exact function. > > We'll have to disagree there. I feel it is much more generic to > the defines that pull in stuff. THen change the subject or open your own thread, please. >> > Not at all what I meant. Flexible about what NTPsec builds on, not >> > flexible about the end result. >> >> You were arguing for defining _GNU_SOURCE, were you not? > > Nope. Yes you were. You claim Humpty-Dumpty privileges a lot, so just to remind you of your exact words: --8<---cut here---start->8--- _GNU_SOURCE should not always be defined, but it does need to be defined in certain cases. For example, on glibc < 2.10, you need to define it to get strnlen() and struct ifreq. >From glibc 2.10, you instead need _POSIX_C_SOURCE >= 200809L --8<---cut here---end--->8--- >> Yet you keep arguing that _GNU_SOURCE should or could be defined, > > Uh, no. I'm not sure who you are arguing with on that. I'm just > reminding folks of things recently learned on gpsd about the feature > macro thing. Well, you can do whatever you want in gpsd. This is ntpsec and even if there is an actual need to define _GNU_SOURCE for certain long dead versions of glibc (which I doubt, that is just the big sledgehammer to pull in everything at once if you don't know what you actually wanted/needed), that is no reason to do it in general, exactly because it is incompatible with the API that ntpsec is supposed to use. In summary, ctx.env.CFLAGS = ["-std=c99", "-D_POSIX_C_SOURCE=202009L", "-D_XOPEN_SOURCE=600", "-D_DEFAULT_SOURCE"] + ctx.env.CFLAGS in wscript is much closer to the API ntpsec claims to use (the older non-POSIX API are not explicitly mentioned in the docs, but in use they are). The derfinition of _DEFAULT_SOURCE activates a number of BSD and SVID API and on some older systems you might need to use _BSD_SOURCE and _SVID_SOURCE instead (in addition should also work). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
