Re: Cruft

2019-09-17 Thread Hal Murray via devel
> 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.

Re: Cruft

2019-09-17 Thread Matthew Selsky via devel
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

Re: Cruft

2019-09-17 Thread Hal Murray via devel
> 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

Re: Cruft

2019-09-17 Thread Matthew Selsky via devel
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

Re: Cruft

2019-09-17 Thread Hal Murray via devel
> 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

Re: Cruft

2019-09-17 Thread Matthew Selsky via devel
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

More cruft: libntp/netof.c

2019-09-17 Thread Hal Murray via devel
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

2019-09-17 Thread Hal Murray via devel
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

Re: Future directions

2019-09-17 Thread Hal Murray via devel
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

Re: Fwd: Future directions

2019-09-17 Thread James Browning via devel
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

Re: Future directions

2019-09-17 Thread Richard Laager via devel
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

Re: Fwd: Future directions

2019-09-17 Thread Richard Laager via devel
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

Re: Future directions

2019-09-17 Thread Hal Murray via devel
> 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