Re: Cruft
> I'm talking about this snippet that was removed: -#ifdef RLIMIT_MEMLOCK - case RLIMIT_MEMLOCK: - /* ignore - for backward compatibility only */ I fixed the place that used to call it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 09:39:15PM -0700, Hal Murray wrote:
> > Only thing left to revert is missing guards near "switch (rl_what) {"
> > near line 3630 in ntpd/ntp_config.h
>
> The whole point of this change was to get rid of ifdefs that weren't needed
> because the symbols they were checking are in POSIX. Are we running on any
> systems that don't have RLIMIT_NOFILE or RLIMIT_STACK?
I'm talking about this snippet that was removed:
<--->
switch (rl_what) {
-#ifdef RLIMIT_MEMLOCK
- case RLIMIT_MEMLOCK:
- /* ignore - for backward compatibility only */
- break;
-#endif /* RLIMIT_MEMLOCK */
<--->
>
> Is this one of those half-in-POSIX cases where they say this is how to do it,
> but it's optional?
I'm still talking about RLIMIT_MEMLOCK.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
> Only thing left to revert is missing guards near "switch (rl_what) {"
> near line 3630 in ntpd/ntp_config.h
The whole point of this change was to get rid of ifdefs that weren't needed
because the symbols they were checking are in POSIX. Are we running on any
systems that don't have RLIMIT_NOFILE or RLIMIT_STACK?
Is this one of those half-in-POSIX cases where they say this is how to do it,
but it's optional?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 08:42:18PM -0700, Hal Murray wrote:
> > Can you partially revert ...
>
> I thought I had fixed it. Have you done a recent pull? Is the current code
> still broken?
Only thing left to revert is missing guards near "switch (rl_what) {" near line
3630 in ntpd/ntp_config.h
> Again, thanks for catching this.
You're welcome. Friendly nudge poke for using merge requests and peer review
pre-merging into master :-)
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
> Can you partially revert ... I thought I had fixed it. Have you done a recent pull? Is the current code still broken? Again, thanks for catching this. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Sun, Sep 15, 2019 at 06:18:47PM -0700, Hal Murray via devel wrote: > > There are various #ifdefs testing RLIMIT_MEMLOCK and friends > > The Linux man page for setrlimit says: >getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. > So I think we can assume it exists and remove the #ifdefs. > > Any reason not to? getrlimit()/setrlimit() are part of POSIX, but RLIMIT_MEMLOCK is not. This symbol is Linux/BSD-specific. Can you partially revert https://gitlab.com/NTPsec/ntpsec/commit/fb0c11c9db45709448383d1963b4cdf72a442f55#f4db43d91d9d4fe0fe143a20b21c2b3cd3a01a15_3635_3625 and https://gitlab.com/NTPsec/ntpsec/commit/36128757fbb6613fc4cea2705cc3717fbd7dc7fb? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
More cruft: libntp/netof.c
It only contains netof6() which is only used by the test routines. Any reason not to nuke it and the tests? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
More potential cruft
in ntp_debug.h, there is a TPRINT macro. * TPRINT is used where the logger needs to remain even when DEBUG is off. TPRINT is not used in ntpd/, DPRINT is not used in libntp/ I assume the idea is that a library would always be built with debugging built in. If you used the library, you could provide your own way to adjust debug level. This is tangled up with two copies of declcond.h one in ntpd/ and the other in include/ --- There was cleanup in this area a while ago. I suspect the TPRINT/DPRINT split preserved the old way without understanding why it was needed. My vote would be to nuke TPRINT, change all (6.5) references to it to use DPRINT and eliminate both copies of declcond.h by moving the one critical line to ntp_debug.h (The 0.5 is a comment.) This seems like the sort of thing you would have done if you had noticed, but maybe there is something going on that I don't understand yet. Do you have serious plans to export libntp? Does it need debugging? ... -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Future directions
rlaa...@wiktel.com said: > >From the draft, it sounds like this might be as simple as NOT specifying a > port on the socket, which is what other implementations do. Unfortunately, the code isn't written that way. There is no socket for each server. There is one for each interface. It uses sendto. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fwd: Future directions
On Tue, Sep 17, 2019 at 1:23 PM Richard Laager wrote: > On 9/16/19 6:08 PM, James Browning via devel wrote: > > - additions to the DNS code to allow non-A/ pools. (cname/srv > probably) > > Is it not following CNAMEs already? I haven't checked. > No, it seems not to. Also since typing that I have checked the foolish notion I had and corrected it. cnames don't seem to be returnable in groups. > - less awful asccidoctor support > > What's the issue here? I might be able to help. > - No detection by waf helpers. - _Adds_ ruby as a required language. - does not properly handle the inclusions. - messes up the style sheet. Mostly a reminder to myself to work on it (possibly handing bits off) instead of the stuff I am doing now. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Future directions
On 9/16/19 1:33 AM, Hal Murray via devel wrote: > Port randomization: > https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04 > I'd guess somewhere between a day and a week to implement this. >From the draft, it sounds like this might be as simple as NOT specifying a port on the socket, which is what other implementations do. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fwd: Future directions
On 9/16/19 6:08 PM, James Browning via devel wrote: > - additions to the DNS code to allow non-A/ pools. (cname/srv probably) Is it not following CNAMEs already? I haven't checked. > - less awful asccidoctor support What's the issue here? I might be able to help. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Future directions
> This is exactly what futexes are for. Is there a standard recipe for using them in shared memory when the processes using them can start/stop/crash at any time? I see 2 problem areas. One is initializing the futex. The other is recovering from a crash while the futex was busy. (lock locked, or whatever) --- The man page for shmget says a new segment is full of 0s. If we assume the writer will create the segment, it can use a flag in the segment to mark that whatever a futex needs has been initialized. I assume the same logic works for a mutex and semaphore so we can do it with POSIX code. I haven't worked out the details, but it looks like pthread_mutex_lock and friends return an error if the thread/process owning the mutex crashes. Using the futex/mutex requires that the reader be able to write the segment. Thanks for the poke. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
