Re: stdio: fclose(3), fopen(3): intended locking hierarchy?
On Wed, Nov 25, 2020 at 4:23 PM Scott Cheloha
wrote:
> In stdio, which lock are you supposed to take first? The global
> sfp_mutex or the per-FILE lock?
>
> In __sfp() we hold sfp_mutex while iterating through the pool (unsure
> what else to call it) of FILEs. No two threads can modify the pool at
> the same time:
>
...
> Note that we set _flags to 1 to reserve it for the current thread
> before leaving sfp_mutex. Note also that we don't take the per-FILE
> lock before reading each FILE's _flags.
>
> Then look at fclose(3):
>
...
> We check if _flags is zero without any lock. I'm unsure if this is
> safe.
>
> However, we then clean up under the FILE's lock and set _flags to zero
> without sfp_mutex.
>
> ... that can't be right.
>
> So, what to do? My immediate thought was to export sfp_mutex and
> enter it before writing _flags (diff attached). But then the global
> sfp_mutex is "higher" in the locking hierarchy than the per-FILE lock.
> That doesn't seem quite right to me.
>
> We also modify _flags all over stdio without sfp_mutex, so the rule is
> inconsistent.
>
> Another possibility is to take the per-FILE lock when examining each
> FILE's _flags during __sfp(). That would be costlier, but then the
> hierarchy would be reversed.
>
> Thoughts?
>
Let's say that we're willing to presume that changing _flags from
one non-zero value to another non-zero value will never result in
a zero value being visible either on this CPU or another one. If
that's not true, then there's more to fix, but let's start with
that assumption.
Given that, I think the only unsafe item in what you described above
is the setting of _flags to zero in various places without either
holding sfp_mutex or using some sort of membar (or atomic op) to
guarantee all previous changes to the FILE are visible before the
flags change is visible.
My reasoning would be that if the setting of _flags from non-zero
to zero was always the last thing visible, then the code scanning
the list could be sure that a non-zero flags means no one else has
any pending writes to the FILE and it can be allocated. __sfp()'s
setting _flags to 1 to mark it as allocated is made visible to other
threads when it unlocks sfp_mutex.
...but we don't have those membars/atomic-ops, so it's not currently
guaranteed that __sfp() can't allocate a FILE which is still being
updated by a thread that's releasing it. ;(
If strewing membars makes people twitchy (my eye twitches some),
then yeah, your proposal to take sfp_mutex when zeroing _file is
te alternative. Regarding the hierarchy concern, see below.
None of this fixes _fwalk(), which can invoke the callback on
partially created FILEs, even if it were to grab sfp_mutex. I can
imagine a couple directions for fixing that, from setting __SIGN
on not-yet-completed FILEs and clearing it at the end, to full-blown
having __sfp() return a locked FILE and making _fwalk() lock each
FILE before invoking the callback. Note that of the three callbacks
passed to _fwalk(), two end up locking the FILE anyway, so maybe
this is the right direction anyway.
So, the lock hierarchy is then...interesting:
* if you hold sfp_mutex, you can FLOCKFILE a FILE iff _flags == 0
* if _flags != 0, you must lock sfp_mutex before zeroing it and
FUNLOCKFILE and never touch the FILE again before unlocking
sfp_mutex.
Given the assumption at top, I believe that's safe+correct.
The problem case for _fwalk() is _cleanup(), which currently and
explicitly 'cheats' by failing to lock FILE...but I suspect that's
a hold-over from when abort() called atexit() handlers, as it's
supposed to be async-signal-safe and therefore can't take locks.
abort() no longer does that: POSIX withdrew it because, well, it
can't be done safely with an async-signal-safe abort() without
making lots of stdio functions block all signals, which would lead
to torches and pitchforks. This is presumably _also_ why _fwalk()
doesn't lock sfp_mutex when it 'obviously' should, so that's fixable
too! Woot!
So yeah, maybe it does work to:
1) make __sfp() FLOCKFILE() the allocated FILE before unlocking sfp_mutex
2) update f{,d,mem,un}open() and open_*memstream() to match (1), unlocking
in all paths when the FILE is safe to be accessed by _fwalk(), and
locking
sfp_mutex around the zeroing of _flags.
3) make fclose() and freopen() also lock sfp_mutex around the zeroing of
_flags
(should add an _frelease() to findfp.c that does this dance for (2) and
(3))
4) make _fwalk() take sfp_mutex, and maybe also a FILE* so the setting of
__SIGN can be done under the lock?
5) decide how/whether to handle adjust the FLOCKFILE placement in the
_fwalk()
tree: is the testing of the "is line-buffered" flag in lflush() safe
without
a lock? Mumble...
Now, back to that first assumption: if you're not willing to assume
it then the "is allocated" test needs to not use _flags but be some
other state change which can be relied on to not have false-positives,
but otherwise
Re: sio_open.3: clarify what sio_start() does
On Fri Nov 27, 2020 at 3:05 PM -03, Alexandre Ratchov wrote: > this wording is shorter and more precise and complete. > > ok? > > Index: sio_open.3 > === > RCS file: /cvs/src/lib/libsndio/sio_open.3,v > retrieving revision 1.51 > diff -u -p -r1.51 sio_open.3 > --- sio_open.3 20 Nov 2020 12:09:45 - 1.51 > +++ sio_open.3 27 Nov 2020 18:02:16 - > @@ -387,17 +387,17 @@ bitmasks should always be used. > .Ss Starting and stopping the device > The > .Fn sio_start > -function puts the device in a waiting state: > -the device will wait for playback data to be provided > -(using the > -.Fn sio_write > -function). > -Once enough data is queued to ensure that play buffers > -will not underrun, actual playback is started automatically. > -If record mode only is selected, then recording starts > -immediately. > +function prepares the devices to start. Using 'devices' instead of 'device' here is different from the current version. Is that intentional? > +Once the play buffer is full, i.e. > +.Fa sio_par.bufsz > +samples are queued with > +.Fn sio_write , > +playback starts automatically. > +If record mode only is selected, then > +.Fn sio_start > +starts recording immediately. > In full-duplex mode, playback and recording will start > -synchronously as soon as enough data to play is available. > +synchronously as soon as the play buffer is full. > .Pp > The > .Fn sio_stop Thanks for looking into this, it's much clearer now. Érico
Re: lld for macppc kernel
> Date: Mon, 23 Nov 2020 22:59:19 -0500
> From: George Koehler
>
> With this diff, lld can link macppc's kernel.
>
> The first part of the diff adds R_PPC_ADDR24 to lld. I didn't find
> code in upstream lld's git for R_PPC_ADDR24. We need R_PPC_ADDR24 for
> "ba" and "bla" in locore.S.
I suppose llvm doesn't generate these relocations.
> The second part edits the kernel's Makefile.macppc. I add gapdummy
> (like in Makefile.powerpc64) to avoid an lld error. I also adapt a
> part of Makefile.i386, so my powerpc64 can build and link the macppc
> kernel. (I didn't boot that kernel.) My macppc can now build, link,
> and boot the GENERIC kernel with either ld.bfd or ld.lld.
>
> ok to commit?
ok kettenis@
> Index: gnu/llvm/lld/ELF/Arch/PPC.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/PPC.cpp,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PPC.cpp
> --- gnu/llvm/lld/ELF/Arch/PPC.cpp 3 Aug 2020 14:32:29 - 1.1.1.1
> +++ gnu/llvm/lld/ELF/Arch/PPC.cpp 23 Nov 2020 19:49:47 -
> @@ -220,6 +220,7 @@ RelExpr PPC::getRelExpr(RelType type, co
>case R_PPC_ADDR16_HA:
>case R_PPC_ADDR16_HI:
>case R_PPC_ADDR16_LO:
> + case R_PPC_ADDR24:
>case R_PPC_ADDR32:
> return R_ABS;
>case R_PPC_DTPREL16:
> @@ -344,6 +345,7 @@ void PPC::relocateOne(uint8_t *loc, RelT
> break;
>}
>case R_PPC_REL24:
> + case R_PPC_ADDR24:
>case R_PPC_LOCAL24PC:
>case R_PPC_PLTREL24: {
> uint32_t mask = 0x03FC;
> Index: sys/arch/macppc/conf/Makefile.macppc
> ===
> RCS file: /cvs/src/sys/arch/macppc/conf/Makefile.macppc,v
> retrieving revision 1.99
> diff -u -p -r1.99 Makefile.macppc
> --- sys/arch/macppc/conf/Makefile.macppc 7 Nov 2019 20:42:28 -
> 1.99
> +++ sys/arch/macppc/conf/Makefile.macppc 23 Nov 2020 19:49:49 -
> @@ -53,6 +53,13 @@ CFLAGS=${DEBUG} ${CWARNFLAGS} ${CMACHF
> AFLAGS= -D_LOCORE ${CMACHFLAGS}
> LINKFLAGS= -N -Ttext 100114 -e start --warn-common -nopie
>
> +.if ${MACHINE} == "powerpc64"
> +CFLAGS+= -m32
> +AFLAGS+= -m32
> +LDFLAGS= -melf32ppc
> +LINKFLAGS+= ${LDFLAGS}
> +.endif
> +
> HOSTCC?= ${CC}
> HOSTED_CPPFLAGS=${CPPFLAGS:S/^-nostdinc$//}
> HOSTED_CFLAGS= ${CFLAGS}
> @@ -123,12 +130,16 @@ ioconf.o: ioconf.c
> ld.script: ${_machdir}/conf/ld.script
> cp ${_machdir}/conf/ld.script $@
>
> +gapdummy.o:
> + echo '__asm(".section .rodata,\"a\"");' > gapdummy.c
> + ${CC} -c ${CFLAGS} ${CPPFLAGS} gapdummy.c -o $@
> +
> makegap.sh:
> cp $S/conf/makegap.sh $@
>
> -MAKE_GAP = LD="${LD}" sh makegap.sh 0x # guaranteed illegal
> +MAKE_GAP = LD="${LD}" sh makegap.sh 0x gapdummy.o
>
> -gap.o: Makefile makegap.sh vers.o
> +gap.o: Makefile makegap.sh gapdummy.o vers.o
> ${MAKE_GAP}
>
> vers.o: ${SYSTEM_DEP:Ngap.o}
> @@ -137,7 +148,7 @@ vers.o: ${SYSTEM_DEP:Ngap.o}
>
> clean:
> rm -f *bsd *bsd.gdb *.[dio] [a-z]*.s assym.* \
> - gap.link ld.script lorder makegap.sh param.c
> + gap.link gapdummy.c ld.script lorder makegap.sh param.c
>
> cleandir: clean
> rm -f Makefile *.h ioconf.c options machine ${_mach} vers.c
>
>
Re: slaacd(8): unexpected FD
On Fri, Nov 27, 2020 at 09:41:21PM +0100, Florian Obser wrote:
> An interface might have disappeared or switched rdomains while we
> waited for a FD. It's not a fatal condition if it arrives late.
That makes sense.
> I can only get it to lose the race by introducing a sleep in the
> parent process, but the race is still there. Found while implementing
> rdomain support in rad(8) using the same pattern.
I did not manage to reproduce this in rdomain rad, but I didn't try very
hard. I understand the race now.
ok tb
> I'm now wondering if it would be better to listen on the route socket
> for interface arrivals / departure in the parent process instead of
> the frontend asking for a raw socket to be opened. But that's a diff
> for another time.
>
> OK?
>
> diff --git frontend.c frontend.c
> index 4b3f575611e..7efbe50df20 100644
> --- frontend.c
> +++ frontend.c
> @@ -1164,9 +1164,14 @@ set_icmp6sock(int icmp6sock, int rdomain)
> }
> }
>
> - if (icmp6sock != -1)
> - fatalx("received unneeded ICMPv6 socket for rdomain %d",
> - rdomain);
> + if (icmp6sock != -1) {
> + /*
> + * The interface disappeared or changed rdomain while we were
> + * waiting for the parent process to open the raw socket.
> + */
> + close(icmp6sock);
> + return;
> + }
>
> LIST_FOREACH (iface, &interfaces, entries) {
> if (event_initialized(&iface->icmp6ev->ev) &&
>
> --
> I'm not entirely sure you are real.
>
Re: lld for macppc kernel
On Mon, 23 Nov 2020 22:59:19 -0500 George Koehler wrote: > My macppc can now build, link, > and boot the GENERIC kernel with either ld.bfd or ld.lld. ld.lld with my diff can link macppc kernels GENERIC, GENERIC.MP, and RAMDISK, and I can boot and run them, but all macppc kernels from lld have &etext == 0x1034 which is far too high. $ nm bsd|grep etext 1034 T etext ofwboot with ld.lld doesn't work; I needed to relink ofwboot with ld.bfd to boot any kernel. ofwboot also had &etext == 0x1034, but I don't know what caused ofwboot to fail. I still ask if ld.lld diff for R_PPC_ADDR24 is ok.
Re: slaacd(8): changing rdomain
On Fri, Nov 27, 2020 at 09:34:59PM +0100, Florian Obser wrote:
>
> Handle the case of an autoconf interface changing its rdomain.
>
> To avoide code duplication have get_icmp6ev_by_rdomain() either return
> an existing icmp6ev in the correct rdomain or allocate one.
>
> OK?
ok tb.
>
> diff --git frontend.c frontend.c
> index 3bf418ba31e..624ff5562f3 100644
> --- frontend.c
> +++ frontend.c
> @@ -502,7 +502,6 @@ void
> update_iface(uint32_t if_index, char* if_name)
> {
> struct iface*iface;
> - struct icmp6_ev *icmp6ev;
> struct imsg_ifinfo imsg_ifinfo;
> int flags, xflags, ifrdomain;
>
> @@ -516,32 +515,29 @@ update_iface(uint32_t if_index, char* if_name)
> if((ifrdomain = get_ifrdomain(if_name)) == -1)
> return;
>
> - if ((iface = get_iface_by_id(if_index)) == NULL) {
> + iface = get_iface_by_id(if_index);
> +
> + if (iface != NULL) {
> + if (iface->rdomain != ifrdomain) {
> + if (iface->icmp6ev != NULL) {
> + iface->icmp6ev->refcnt--;
> + if (iface->icmp6ev->refcnt == 0) {
> + event_del(&iface->icmp6ev->ev);
> + close(EVENT_FD(&iface->icmp6ev->ev));
> + free(iface->icmp6ev);
> + }
> + iface->icmp6ev = NULL;
> + }
> + iface->rdomain = ifrdomain;
> + iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
> + }
> + } else {
> if ((iface = calloc(1, sizeof(*iface))) == NULL)
> fatal("calloc");
> iface->if_index = if_index;
> iface->rdomain = ifrdomain;
> + iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
>
> - if ((icmp6ev = get_icmp6ev_by_rdomain(ifrdomain)) == NULL) {
> - if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
> - fatal("calloc");
> - icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
> - icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
> - icmp6ev->rcvmhdr.msg_name = (caddr_t)&icmp6ev->from;
> - icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
> - icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
> - icmp6ev->rcvmhdr.msg_iovlen = 1;
> - icmp6ev->rcvmhdr.msg_controllen =
> - CMSG_SPACE(sizeof(struct in6_pktinfo)) +
> - CMSG_SPACE(sizeof(int));
> - if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
> - rcvmhdr.msg_controllen)) == NULL)
> - fatal("malloc");
> - frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
> - &ifrdomain, sizeof(ifrdomain));
> - }
> - iface->icmp6ev = icmp6ev;
> - iface->icmp6ev->refcnt++;
> LIST_INSERT_HEAD(&interfaces, iface, entries);
> }
>
> @@ -1121,13 +1117,35 @@ struct icmp6_ev*
> get_icmp6ev_by_rdomain(int rdomain)
> {
> struct iface*iface;
> + struct icmp6_ev *icmp6ev = NULL;
>
> LIST_FOREACH (iface, &interfaces, entries) {
> - if (iface->rdomain == rdomain)
> - return (iface->icmp6ev);
> + if (iface->rdomain == rdomain) {
> + icmp6ev = iface->icmp6ev;
> + break;
> + }
> }
>
> - return (NULL);
> + if (icmp6ev == NULL) {
> + if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
> + fatal("calloc");
> + icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
> + icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
> + icmp6ev->rcvmhdr.msg_name = (caddr_t)&icmp6ev->from;
> + icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
> + icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
> + icmp6ev->rcvmhdr.msg_iovlen = 1;
> + icmp6ev->rcvmhdr.msg_controllen =
> + CMSG_SPACE(sizeof(struct in6_pktinfo)) +
> + CMSG_SPACE(sizeof(int));
> + if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
> + rcvmhdr.msg_controllen)) == NULL)
> + fatal("malloc");
> + frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
> + &rdomain, sizeof(rdomain));
> + }
> + icmp6ev->refcnt++;
> + return (icmp6ev);
> }
>
> void
> --
> 2.29.2
>
>
>
> --
> I'm not entirely sure you are real.
>
slaacd(8): unexpected FD
An interface might have disappeared or switched rdomains while we
waited for a FD. It's not a fatal condition if it arrives late.
I can only get it to lose the race by introducing a sleep in the
parent process, but the race is still there. Found while implementing
rdomain support in rad(8) using the same pattern.
I'm now wondering if it would be better to listen on the route socket
for interface arrivals / departure in the parent process instead of
the frontend asking for a raw socket to be opened. But that's a diff
for another time.
OK?
diff --git frontend.c frontend.c
index 4b3f575611e..7efbe50df20 100644
--- frontend.c
+++ frontend.c
@@ -1164,9 +1164,14 @@ set_icmp6sock(int icmp6sock, int rdomain)
}
}
- if (icmp6sock != -1)
- fatalx("received unneeded ICMPv6 socket for rdomain %d",
- rdomain);
+ if (icmp6sock != -1) {
+ /*
+* The interface disappeared or changed rdomain while we were
+* waiting for the parent process to open the raw socket.
+*/
+ close(icmp6sock);
+ return;
+ }
LIST_FOREACH (iface, &interfaces, entries) {
if (event_initialized(&iface->icmp6ev->ev) &&
--
I'm not entirely sure you are real.
slaacd(8): unref_icmp6ev()
Reduce code duplication by introducing unref_icmp6ev()
OK?
diff --git frontend.c frontend.c
index 624ff5562f3..4b3f575611e 100644
--- frontend.c
+++ frontend.c
@@ -92,6 +92,7 @@ void get_lladdr(char *, struct ether_addr *, struct
sockaddr_in6 *);
struct iface *get_iface_by_id(uint32_t);
voidremove_iface(uint32_t);
struct icmp6_ev*get_icmp6ev_by_rdomain(int);
+voidunref_icmp6ev(struct iface *);
voidset_icmp6sock(int, int);
voidsend_solicitation(uint32_t);
#ifndefSMALL
@@ -519,15 +520,7 @@ update_iface(uint32_t if_index, char* if_name)
if (iface != NULL) {
if (iface->rdomain != ifrdomain) {
- if (iface->icmp6ev != NULL) {
- iface->icmp6ev->refcnt--;
- if (iface->icmp6ev->refcnt == 0) {
- event_del(&iface->icmp6ev->ev);
- close(EVENT_FD(&iface->icmp6ev->ev));
- free(iface->icmp6ev);
- }
- iface->icmp6ev = NULL;
- }
+ unref_icmp6ev(iface);
iface->rdomain = ifrdomain;
iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
}
@@ -1102,14 +1095,7 @@ remove_iface(uint32_t if_index)
LIST_REMOVE(iface, entries);
- if (iface->icmp6ev != NULL) {
- iface->icmp6ev->refcnt--;
- if (iface->icmp6ev->refcnt == 0) {
- event_del(&iface->icmp6ev->ev);
- close(EVENT_FD(&iface->icmp6ev->ev));
- free(iface->icmp6ev);
- }
- }
+ unref_icmp6ev(iface);
free(iface);
}
@@ -1148,6 +1134,20 @@ get_icmp6ev_by_rdomain(int rdomain)
return (icmp6ev);
}
+void
+unref_icmp6ev(struct iface *iface)
+{
+ if (iface->icmp6ev != NULL) {
+ iface->icmp6ev->refcnt--;
+ if (iface->icmp6ev->refcnt == 0) {
+ event_del(&iface->icmp6ev->ev);
+ close(EVENT_FD(&iface->icmp6ev->ev));
+ free(iface->icmp6ev);
+ }
+ iface->icmp6ev = NULL;
+ }
+}
+
void
set_icmp6sock(int icmp6sock, int rdomain)
{
--
2.29.2
--
I'm not entirely sure you are real.
slaacd(8): changing rdomain
Handle the case of an autoconf interface changing its rdomain.
To avoide code duplication have get_icmp6ev_by_rdomain() either return
an existing icmp6ev in the correct rdomain or allocate one.
OK?
diff --git frontend.c frontend.c
index 3bf418ba31e..624ff5562f3 100644
--- frontend.c
+++ frontend.c
@@ -502,7 +502,6 @@ void
update_iface(uint32_t if_index, char* if_name)
{
struct iface*iface;
- struct icmp6_ev *icmp6ev;
struct imsg_ifinfo imsg_ifinfo;
int flags, xflags, ifrdomain;
@@ -516,32 +515,29 @@ update_iface(uint32_t if_index, char* if_name)
if((ifrdomain = get_ifrdomain(if_name)) == -1)
return;
- if ((iface = get_iface_by_id(if_index)) == NULL) {
+ iface = get_iface_by_id(if_index);
+
+ if (iface != NULL) {
+ if (iface->rdomain != ifrdomain) {
+ if (iface->icmp6ev != NULL) {
+ iface->icmp6ev->refcnt--;
+ if (iface->icmp6ev->refcnt == 0) {
+ event_del(&iface->icmp6ev->ev);
+ close(EVENT_FD(&iface->icmp6ev->ev));
+ free(iface->icmp6ev);
+ }
+ iface->icmp6ev = NULL;
+ }
+ iface->rdomain = ifrdomain;
+ iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
+ }
+ } else {
if ((iface = calloc(1, sizeof(*iface))) == NULL)
fatal("calloc");
iface->if_index = if_index;
iface->rdomain = ifrdomain;
+ iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
- if ((icmp6ev = get_icmp6ev_by_rdomain(ifrdomain)) == NULL) {
- if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
- fatal("calloc");
- icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
- icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
- icmp6ev->rcvmhdr.msg_name = (caddr_t)&icmp6ev->from;
- icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
- icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
- icmp6ev->rcvmhdr.msg_iovlen = 1;
- icmp6ev->rcvmhdr.msg_controllen =
- CMSG_SPACE(sizeof(struct in6_pktinfo)) +
- CMSG_SPACE(sizeof(int));
- if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
- rcvmhdr.msg_controllen)) == NULL)
- fatal("malloc");
- frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
- &ifrdomain, sizeof(ifrdomain));
- }
- iface->icmp6ev = icmp6ev;
- iface->icmp6ev->refcnt++;
LIST_INSERT_HEAD(&interfaces, iface, entries);
}
@@ -1121,13 +1117,35 @@ struct icmp6_ev*
get_icmp6ev_by_rdomain(int rdomain)
{
struct iface*iface;
+ struct icmp6_ev *icmp6ev = NULL;
LIST_FOREACH (iface, &interfaces, entries) {
- if (iface->rdomain == rdomain)
- return (iface->icmp6ev);
+ if (iface->rdomain == rdomain) {
+ icmp6ev = iface->icmp6ev;
+ break;
+ }
}
- return (NULL);
+ if (icmp6ev == NULL) {
+ if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
+ fatal("calloc");
+ icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
+ icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
+ icmp6ev->rcvmhdr.msg_name = (caddr_t)&icmp6ev->from;
+ icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
+ icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
+ icmp6ev->rcvmhdr.msg_iovlen = 1;
+ icmp6ev->rcvmhdr.msg_controllen =
+ CMSG_SPACE(sizeof(struct in6_pktinfo)) +
+ CMSG_SPACE(sizeof(int));
+ if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
+ rcvmhdr.msg_controllen)) == NULL)
+ fatal("malloc");
+ frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
+ &rdomain, sizeof(rdomain));
+ }
+ icmp6ev->refcnt++;
+ return (icmp6ev);
}
void
--
2.29.2
--
I'm not entirely sure you are real.
sio_open.3: clarify what sio_start() does
this wording is shorter and more precise and complete. ok? Index: sio_open.3 === RCS file: /cvs/src/lib/libsndio/sio_open.3,v retrieving revision 1.51 diff -u -p -r1.51 sio_open.3 --- sio_open.3 20 Nov 2020 12:09:45 - 1.51 +++ sio_open.3 27 Nov 2020 18:02:16 - @@ -387,17 +387,17 @@ bitmasks should always be used. .Ss Starting and stopping the device The .Fn sio_start -function puts the device in a waiting state: -the device will wait for playback data to be provided -(using the -.Fn sio_write -function). -Once enough data is queued to ensure that play buffers -will not underrun, actual playback is started automatically. -If record mode only is selected, then recording starts -immediately. +function prepares the devices to start. +Once the play buffer is full, i.e. +.Fa sio_par.bufsz +samples are queued with +.Fn sio_write , +playback starts automatically. +If record mode only is selected, then +.Fn sio_start +starts recording immediately. In full-duplex mode, playback and recording will start -synchronously as soon as enough data to play is available. +synchronously as soon as the play buffer is full. .Pp The .Fn sio_stop
Fan Management Framework
Hi,
I recently decided to replace MacOSX on my iMac11,3 27" with OpenBSD.
During the MacOSX times I had to replace the broken HDD with a new SSD.
The new SSD didn't offer pins to attach the sensor cable back, which
was previously attached to the HDD, so I left it loose. This caused
the HDD fan to spin up to maximum over time. On MacOSX there are some
fan control programs with which I could control the fan speed. I
almost forgot about that "fix" over time, but installing OpenBSD on
that machine remembered me of it - You can't overhear it :-)
That made me play around with asmc(4), where I noticed you can not
only read the fan properties, but also set them. I initially was
thinking to make sysctl(8) able to set fan speeds, but what I could
see is that the fan framework there seems to be designed to read
only. Instead of poking around further in sysctl(8), I had the idea
to create a small fan(4) framework layer, which can be controlled
through a device by using a fanctl(8) user-land program.
I don't know if there are other fan sensor controllers which would
allow fan properties control. If yes, they potentially could attach
to the same fan framework. If not, the fan framework probably doesn't
make much sense only to be used by asmc(4).
Some example:
...
asmc0 at acpi0: SMC_ (smc-piketon) addr 0x300/0x20: rev 1.59f559, 297
keys
fan0 at asmc0
...
bigmac# sysctl | grep fan
hw.sensors.asmc0.fan0=998 RPM (ODD, right mid rear)
hw.sensors.asmc0.fan1=3677 RPM (HDD, center mid rear)
hw.sensors.asmc0.fan2=939 RPM (CPU, left lower rear)
bigmac# ./fanctl
driver=asmc0
fan0.id=ODD, right mid rear
fan0.act=999 RPM
fan0.min=1000 RPM
fan0.max=3800 RPM
fan0.saf=0 RPM
fan0.tgt=1000 RPM
fan1.id=HDD, center mid rear
fan1.act=3693 RPM
fan1.min=1100 RPM
fan1.max=5500 RPM
fan1.saf=0 RPM
fan1.tgt=3700 RPM
fan2.id=CPU, left lower rear
fan2.act=939 RPM
fan2.min=940 RPM
fan2.max=2100 RPM
fan2.saf=0 RPM
fan2.tgt=940 RPM
bigmac# ./fanctl fan1.act
fan1.act=3729
bigmac# ./fanctl fan1.max
fan1.max=5500
bigmac# ./fanctl fan1.max=1000
fan1.max: 5500 -> 1000
*silence* :-)
bigmac# ./fanctl fan1.act
fan1.act=1002
Attached a very initial coding, but basically works for me.
Maybe the idea is totally stupid, and the use cases are very
rare. I don't know. Therefore I would appreciate some feedback.
Thanks,
Marcus
Index: etc/MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 MAKEDEV.common
--- etc/MAKEDEV.common 6 Jul 2020 06:11:26 - 1.111
+++ etc/MAKEDEV.common 27 Nov 2020 16:13:39 -
@@ -170,6 +170,7 @@ target(all, bpf)dnl
target(all, kcov)dnl
target(all, dt)dnl
target(all, kstat)dnl
+target(all, fan, 0)dnl
dnl
_mkdev(all, {-all-}, {-dnl
show_target(all)dnl
@@ -535,3 +536,6 @@ __devitem(dt, dt, Dynamic Tracer)dnl
_mkdev(dt, dt, {-M dt c major_dt_c 0 600-})dnl
__devitem(kstat, kstat, Kernel Statistics)dnl
_mkdev(kstat, kstat, {-M kstat c major_kstat_c 0 640-})dnl
+__devitem(fan, fan*, Fan Management Framework)dnl
+_mkdev(fan, fan*, {-M fan$U c major_fan_c $U 600
+ MKlist[${#MKlist[*]}]=";[ -e fan ] || ln -s fan$U fan"-})dnl
Index: etc/etc.amd64/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV.md,v
retrieving revision 1.76
diff -u -p -u -p -r1.76 MAKEDEV.md
--- etc/etc.amd64/MAKEDEV.md6 Jul 2020 06:11:26 - 1.76
+++ etc/etc.amd64/MAKEDEV.md27 Nov 2020 16:13:39 -
@@ -98,6 +98,7 @@ _DEV(vscsi, 89)
_DEV(pvbus, 95)
_DEV(switch, 97)
_DEV(kstat, 51)
+_DEV(fan, 48)
dnl
divert(__mddivert)dnl
dnl
Index: sys/arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.72
diff -u -p -u -p -r1.72 conf.c
--- sys/arch/amd64/amd64/conf.c 7 Oct 2020 13:37:33 - 1.72
+++ sys/arch/amd64/amd64/conf.c 27 Nov 2020 16:13:53 -
@@ -173,6 +173,7 @@ cdev_decl(pci);
#include "pvbus.h"
#include "ipmi.h"
#include "switch.h"
+#include "fan.h"
struct cdevsw cdevsw[] =
{
@@ -229,7 +230,7 @@ struct cdevsw cdevsw[] =
cdev_random_init(1,random), /* 45: random data source */
cdev_ocis_init(NPCTR,pctr), /* 46: performance counters */
cdev_disk_init(NRD,rd), /* 47: ram disk driver */
- cdev_notdef(), /* 48 */
+ cdev_fan_init(NFAN,fan),/* 48: Fan Management */
cdev_bktr_init(NBKTR,bktr), /* 49: Bt848 video capture device */
cdev_ksyms_init(NKSYMS,ksyms), /* 50: Kernel symbols device */
cde
Re: wg(4) manpage tweaks
On 11/27/20 1:29 PM, Stuart Henderson wrote: It's not very clear how to fetch the pubkey. OK to add this to wg(4)? Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.6 diff -u -p -r1.6 wg.4 --- wg.424 Nov 2020 16:33:05 - 1.6 +++ wg.427 Nov 2020 12:28:32 - @@ -64,6 +64,9 @@ interface may be configured to recognise .It Key Each peer uses its private key and corresponding public key to identify itself to others. +The public key may be displayed by running +.Xr ifconfig 8 +as root after configuring the private key. A peer configures a .Nm wg interface with its own private key and with the public keys of its peers. @@ -138,9 +141,11 @@ but demonstrates two interfaces on the s .Bd -literal #!/bin/sh +# create interfaces, set random private keys ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1 ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2 +# retrieve the public keys associated with the private keys PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`" PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`" I have no powers over the OK, but I completely agree it wasn't really clear. smime.p7s Description: S/MIME Cryptographic Signature
Re: wg(4) manpage tweaks
On Fri, Nov 27, 2020 at 02:28:42PM +, Stuart Henderson wrote: > On 2020/11/27 14:17, Jason McIntyre wrote: > > On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote: > > > On 2020/11/27 13:41, Jason McIntyre wrote: > > > > > +++ wg.4 27 Nov 2020 12:28:32 - > > > > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > > > > .It Key > > > > > Each peer uses its private key and corresponding public key to > > > > > identify itself to others. > > > > > +The public key may be displayed by running > > > > > +.Xr ifconfig 8 > > > > > +as root after configuring the private key. > > > > > A peer configures a > > > > > .Nm wg > > > > > interface with its own private key and with the public keys of its > > > > > peers. > > > > > > > > i'm not sure about this text. wouldn;t the "Keys" section make more > > > > sense? the "Keys" section itself says: > > > > > > > > When an interface has a private key set with wgkey, the > > > > corresponding public key is shown in the status output of > > > > the interface, like so: > > > > > > > >wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > > > > > > > maybe we should just elaborate here? > > > > > > Ah yes, that does seem a better place, maybe this helps, though > > > perhaps the addition to the example script is enough to give the > > > hint anyway. > > > > > > Index: man4/wg.4 > > > === > > > RCS file: /cvs/src/share/man/man4/wg.4,v > > > retrieving revision 1.7 > > > diff -u -p -r1.7 wg.4 > > > --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 > > > +++ man4/wg.4 27 Nov 2020 14:08:56 - > > > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st > > > When an interface has a private key set with > > > .Nm wgkey , > > > the corresponding > > > -public key is shown in the status output of the interface, like so: > > > +public key is shown in the status output of the interface > > > +displayed by > > > +.Xr ifconfig 8 > > > +when run as root, like so: > > > .Bd -literal -offset indent > > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > > .Ed > > > > > > > > > > fine by me. i tried to think if we had any precedent in the man pages > > for this, where output is exposed by root, but couldn't. i thought our > > wireless interfaces did sth like that. > > > > i also tried to shorten your text but couldn;t come up with anything > > better. > > so ok. > > jmc > > > > Alternatively: > > Index: wg.4 > === > RCS file: /cvs/src/share/man/man4/wg.4,v > retrieving revision 1.7 > diff -u -p -r1.7 wg.4 > --- wg.4 27 Nov 2020 14:04:49 - 1.7 > +++ wg.4 27 Nov 2020 14:28:03 - > @@ -125,8 +125,9 @@ When an interface has a private key set > .Nm wgkey , > the corresponding > public key is shown in the status output of the interface, like so: > -.Bd -literal -offset indent > -wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > +.Bd -literal > +# ifconfig wg1 | grep wgpubkey > + wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > .Ed > .Sh EXAMPLES > Create two > this is shorter (good), but less explicit about the need for root (less good). i guess it's a trade off. i think on balance i like the way you've done it here, but i'm fine either way. i'd remove ", like so" though. also i don;t think you should remove the indent - it would make the openssl example above it look wonky. jmc
Re: wg(4) manpage tweaks
On 2020/11/27 14:17, Jason McIntyre wrote: > On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote: > > On 2020/11/27 13:41, Jason McIntyre wrote: > > > > +++ wg.427 Nov 2020 12:28:32 - > > > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > > > .It Key > > > > Each peer uses its private key and corresponding public key to > > > > identify itself to others. > > > > +The public key may be displayed by running > > > > +.Xr ifconfig 8 > > > > +as root after configuring the private key. > > > > A peer configures a > > > > .Nm wg > > > > interface with its own private key and with the public keys of its > > > > peers. > > > > > > i'm not sure about this text. wouldn;t the "Keys" section make more > > > sense? the "Keys" section itself says: > > > > > >When an interface has a private key set with wgkey, the > > >corresponding public key is shown in the status output of > > >the interface, like so: > > > > > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > > > > > maybe we should just elaborate here? > > > > Ah yes, that does seem a better place, maybe this helps, though > > perhaps the addition to the example script is enough to give the > > hint anyway. > > > > Index: man4/wg.4 > > === > > RCS file: /cvs/src/share/man/man4/wg.4,v > > retrieving revision 1.7 > > diff -u -p -r1.7 wg.4 > > --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 > > +++ man4/wg.4 27 Nov 2020 14:08:56 - > > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st > > When an interface has a private key set with > > .Nm wgkey , > > the corresponding > > -public key is shown in the status output of the interface, like so: > > +public key is shown in the status output of the interface > > +displayed by > > +.Xr ifconfig 8 > > +when run as root, like so: > > .Bd -literal -offset indent > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > .Ed > > > > > > fine by me. i tried to think if we had any precedent in the man pages > for this, where output is exposed by root, but couldn't. i thought our > wireless interfaces did sth like that. > > i also tried to shorten your text but couldn;t come up with anything > better. > so ok. > jmc > Alternatively: Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.7 diff -u -p -r1.7 wg.4 --- wg.427 Nov 2020 14:04:49 - 1.7 +++ wg.427 Nov 2020 14:28:03 - @@ -125,8 +125,9 @@ When an interface has a private key set .Nm wgkey , the corresponding public key is shown in the status output of the interface, like so: -.Bd -literal -offset indent -wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= +.Bd -literal +# ifconfig wg1 | grep wgpubkey + wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= .Ed .Sh EXAMPLES Create two
Re: wg(4) manpage tweaks
On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote: > On 2020/11/27 13:41, Jason McIntyre wrote: > > > +++ wg.4 27 Nov 2020 12:28:32 - > > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > > .It Key > > > Each peer uses its private key and corresponding public key to > > > identify itself to others. > > > +The public key may be displayed by running > > > +.Xr ifconfig 8 > > > +as root after configuring the private key. > > > A peer configures a > > > .Nm wg > > > interface with its own private key and with the public keys of its peers. > > > > i'm not sure about this text. wouldn;t the "Keys" section make more > > sense? the "Keys" section itself says: > > > > When an interface has a private key set with wgkey, the > > corresponding public key is shown in the status output of > > the interface, like so: > > > >wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > > > maybe we should just elaborate here? > > Ah yes, that does seem a better place, maybe this helps, though > perhaps the addition to the example script is enough to give the > hint anyway. > > Index: man4/wg.4 > === > RCS file: /cvs/src/share/man/man4/wg.4,v > retrieving revision 1.7 > diff -u -p -r1.7 wg.4 > --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 > +++ man4/wg.4 27 Nov 2020 14:08:56 - > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st > When an interface has a private key set with > .Nm wgkey , > the corresponding > -public key is shown in the status output of the interface, like so: > +public key is shown in the status output of the interface > +displayed by > +.Xr ifconfig 8 > +when run as root, like so: > .Bd -literal -offset indent > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > .Ed > > fine by me. i tried to think if we had any precedent in the man pages for this, where output is exposed by root, but couldn't. i thought our wireless interfaces did sth like that. i also tried to shorten your text but couldn;t come up with anything better. so ok. jmc
Re: wg(4) manpage tweaks
On 2020/11/27 13:41, Jason McIntyre wrote: > > +++ wg.427 Nov 2020 12:28:32 - > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > .It Key > > Each peer uses its private key and corresponding public key to > > identify itself to others. > > +The public key may be displayed by running > > +.Xr ifconfig 8 > > +as root after configuring the private key. > > A peer configures a > > .Nm wg > > interface with its own private key and with the public keys of its peers. > > i'm not sure about this text. wouldn;t the "Keys" section make more > sense? the "Keys" section itself says: > >When an interface has a private key set with wgkey, the >corresponding public key is shown in the status output of >the interface, like so: > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > maybe we should just elaborate here? Ah yes, that does seem a better place, maybe this helps, though perhaps the addition to the example script is enough to give the hint anyway. Index: man4/wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.7 diff -u -p -r1.7 wg.4 --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 +++ man4/wg.4 27 Nov 2020 14:08:56 - @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st When an interface has a private key set with .Nm wgkey , the corresponding -public key is shown in the status output of the interface, like so: +public key is shown in the status output of the interface +displayed by +.Xr ifconfig 8 +when run as root, like so: .Bd -literal -offset indent wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= .Ed > i agree a bit of explanation makes sense here. saying that, you should > really join "create interfaces" and "set random private keys" with a > semicolon or "and" or somesuch, not a comma. I've committed that with a semicolon.
Re: wg(4) manpage tweaks
On Fri, Nov 27, 2020 at 12:29:01PM +, Stuart Henderson wrote: > It's not very clear how to fetch the pubkey. OK to add this to wg(4)? > hi. > Index: wg.4 > === > RCS file: /cvs/src/share/man/man4/wg.4,v > retrieving revision 1.6 > diff -u -p -r1.6 wg.4 > --- wg.4 24 Nov 2020 16:33:05 - 1.6 > +++ wg.4 27 Nov 2020 12:28:32 - > @@ -64,6 +64,9 @@ interface may be configured to recognise > .It Key > Each peer uses its private key and corresponding public key to > identify itself to others. > +The public key may be displayed by running > +.Xr ifconfig 8 > +as root after configuring the private key. > A peer configures a > .Nm wg > interface with its own private key and with the public keys of its peers. i'm not sure about this text. wouldn;t the "Keys" section make more sense? the "Keys" section itself says: When an interface has a private key set with wgkey, the corresponding public key is shown in the status output of the interface, like so: wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= maybe we should just elaborate here? > @@ -138,9 +141,11 @@ but demonstrates two interfaces on the s > .Bd -literal > #!/bin/sh > > +# create interfaces, set random private keys i agree a bit of explanation makes sense here. saying that, you should really join "create interfaces" and "set random private keys" with a semicolon or "and" or somesuch, not a comma. jmc > ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1 > ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2 > > +# retrieve the public keys associated with the private keys > PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`" > PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`" >
wg(4) manpage tweaks
It's not very clear how to fetch the pubkey. OK to add this to wg(4)? Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.6 diff -u -p -r1.6 wg.4 --- wg.424 Nov 2020 16:33:05 - 1.6 +++ wg.427 Nov 2020 12:28:32 - @@ -64,6 +64,9 @@ interface may be configured to recognise .It Key Each peer uses its private key and corresponding public key to identify itself to others. +The public key may be displayed by running +.Xr ifconfig 8 +as root after configuring the private key. A peer configures a .Nm wg interface with its own private key and with the public keys of its peers. @@ -138,9 +141,11 @@ but demonstrates two interfaces on the s .Bd -literal #!/bin/sh +# create interfaces, set random private keys ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1 ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2 +# retrieve the public keys associated with the private keys PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`" PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`"
Re: Typo fix in nsd.conf.5.in
On Fri, Nov 27, 2020 at 6:29 AM Florian Obser wrote: > > Could you please submit this upstream at > https://github.com/NLnetLabs/nsd > > Thanks, > Florian > Done. https://github.com/NLnetLabs/nsd/commit/800ff7cd44b8bf0eb5586bc538444006751e90a1 > On Fri, Nov 27, 2020 at 05:44:11AM -0500, Eddie Thieda wrote: > > Hello, > > > > Here's a small typo fix, url included if text gets mangled. > > > > http://ix.io/2FEF > > > > --- nsd.conf.5.in Tue Oct 13 06:06:08 2020 > > +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020 > > @@ -161,7 +161,7 @@ anycast instances. Use ip-transparent to be able to l > > turn on later (typical for certain load-balancing). > > .TP > > .B interface:\fR [@port] [servers] [bindtodevice] [setfib] > > -Same as ip\-address (for easy of compatibility with unbound.conf). > > +Same as ip\-address (for easy compatibility with unbound.conf). > > .TP > > .B ip\-transparent:\fR > > Allows NSD to bind to non local addresses. This is useful to have NSD > > > > -- > I'm not entirely sure you are real.
Re: Typo fix in nsd.conf.5.in
Could you please submit this upstream at https://github.com/NLnetLabs/nsd Thanks, Florian On Fri, Nov 27, 2020 at 05:44:11AM -0500, Eddie Thieda wrote: > Hello, > > Here's a small typo fix, url included if text gets mangled. > > http://ix.io/2FEF > > --- nsd.conf.5.in Tue Oct 13 06:06:08 2020 > +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020 > @@ -161,7 +161,7 @@ anycast instances. Use ip-transparent to be able to l > turn on later (typical for certain load-balancing). > .TP > .B interface:\fR [@port] [servers] [bindtodevice] [setfib] > -Same as ip\-address (for easy of compatibility with unbound.conf). > +Same as ip\-address (for easy compatibility with unbound.conf). > .TP > .B ip\-transparent:\fR > Allows NSD to bind to non local addresses. This is useful to have NSD > -- I'm not entirely sure you are real.
Re: Typo fix in nsd.conf.5.in
I think "ease of compatibility" was meant I personally would keep it that way but thanks for the nice catch! Cheers, Emil On 11/27/20 11:44 AM, Eddie Thieda wrote: Hello, Here's a small typo fix, url included if text gets mangled. http://ix.io/2FEF --- nsd.conf.5.in Tue Oct 13 06:06:08 2020 +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020 @@ -161,7 +161,7 @@ anycast instances. Use ip-transparent to be able to l turn on later (typical for certain load-balancing). .TP .B interface:\fR [@port] [servers] [bindtodevice] [setfib] -Same as ip\-address (for easy of compatibility with unbound.conf). +Same as ip\-address (for easy compatibility with unbound.conf). .TP .B ip\-transparent:\fR Allows NSD to bind to non local addresses. This is useful to have NSD
Typo fix in nsd.conf.5.in
Hello, Here's a small typo fix, url included if text gets mangled. http://ix.io/2FEF --- nsd.conf.5.in Tue Oct 13 06:06:08 2020 +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020 @@ -161,7 +161,7 @@ anycast instances. Use ip-transparent to be able to l turn on later (typical for certain load-balancing). .TP .B interface:\fR [@port] [servers] [bindtodevice] [setfib] -Same as ip\-address (for easy of compatibility with unbound.conf). +Same as ip\-address (for easy compatibility with unbound.conf). .TP .B ip\-transparent:\fR Allows NSD to bind to non local addresses. This is useful to have NSD
