ospfd: improve logging when sendig packets fail

Hi, I'd like to improve ospfd's logging when sending a packet fails. I got a debug output from a ospfd user which contains "send packet: error ...". I guess ospfd failed to send an ls ack. With below diff applied it would be clear which packet could not be sent and to which neighbor. OK? Remi

poll init inpcb

Hi, Initialize struct inpcb pool not on demand, but during initialization. Avoids MP problems and removes a global variable. ok? bluhm Index: netinet/in_pcb.c === RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/in_pcb.c,v

pool for unpcb

Hi, Convert struct unpcb malloc(9) to pool_get(9). ok? bluhm Index: kern/uipc_proto.c === RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_proto.c,v retrieving revision 1.17 diff -u -p -r1.17 uipc_proto.c --- kern/uipc_proto.c

[update] libXdmcp 1.1.3

Last update of the series for now. ok? comments ? Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libXdmcp/ChangeLog,v retrieving revision 1.5 diff -u -r1.5 ChangeLog --- ChangeLog 6 Apr 2015 13:43:52 - 1.5 +++

[update] libICE 1.0.10

Let's ride the major bump caused by the xtrans update. There is no other api change though. ok? comments ? Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libICE/ChangeLog,v retrieving revision 1.5 diff -u -r1.5 ChangeLog

Re: portmap(8): Remove an odd call to endpwent(3)

On Sun, 14 Jul 2019 18:34:03 +0300, Vadim Penzin wrote: > portmap(8) does not use setpassent(3) which is the only way of causing a > successful call to getpwnam(3) not to close the password database, > therefore the call to endpwent(3) seems to be unnecessary. Correct, there is no need for

Re: make msgsnd(2) more posix

On Sun, 14 Jul 2019 14:57:54 +0200, Klemens Nanni wrote: > What msgsnd(2) send takes should be of type `struct mymsg`, but our > manual page lackes the struct's name, so this could be improved as well. The struct name is intentionally omitted because the standard doesn't specify one. Callers

[update] libXft 2.3.3

Hi, the patch below updates libXft to version 2.3.3. ok ? comments ? Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libXft/ChangeLog,v retrieving revision 1.6 diff -u -p -u -r1.6 ChangeLog --- ChangeLog 12 Jul 2014

[update] libxtrans 1.4.0

Hi, the patch below updates libxtrans to version 1.4.0. Since there is one removed in a generated file used by other libs, there are also libX11 and libICE major bumps. comments, oks ? Index: lib/libICE/Makefile.bsd-wrapper === RCS

portmap(8): Remove an odd call to endpwent(3)

portmap(8) does not use setpassent(3) which is the only way of causing a successful call to getpwnam(3) not to close the password database, therefore the call to endpwent(3) seems to be unnecessary. The following patch removes the call to endpwent(3): Index: portmap.c

ifstated(8): Fix Hard-Coded Message Size

The following patch replaces the hard-coded message size of 2048 bytes in ifstated.c:rt_msg_handler() with RTM_MAXSIZE (which is currently defined as 2048 bytes) that, I believe, was the intent of the author. Index: ifstated.c ===

route(4): Manpage Clarifications + An Example

Please find below a patch that contains the following: (a) An explanation of alignment of address structures within a routing message; (b) An example (I admit, it is somewhat lengthy --- 146 lines) of a basic parser of route(4) messages. (This message is a follow-up to

Re: make msgsnd(2) more posix

On Fri, Jul 12, 2019 at 10:34:33PM +0200, Moritz Buhl wrote: > while running some ported tests I noticed that msgsnd(2) did not error > when passing a message with mtype < 1, even tho the manual page states: > > mtype is an integer greater than 0 that can be used We also fail to mention that

Re: use SMBIOS for inteldrm panel orientation quirks

> Date: Fri, 12 Jul 2019 14:27:15 +1000 > From: Jonathan Gray > > Use SMBIOS data for panel orientation. Uses BIOS dates when other > strings are generic. > > There are orientation quirks in drm_panel_orientation_quirks.c for: > Acer One 10 (S1003) > Asus T100HA > GPD MicroPC

vfs_lookup: return on read-only file systems

semarie send this fix to tech@ some time ago[0] before any realpath changes, I reported it independently later on[1] while missing his mail. Here is semarie's diff adapted to -current. See both mails for more details. It fixes unveiling files on read-only file systems; this case is tested in

Re: route(4) manual and sockaddrs; ROUNDUP()

Since `sa_len' describes the size of a `sockaddr' (or one of its derivatives) /including/ `sa_len' (maybe I am wrong, but this is my interpretation of the comment `total length' that appears near the definition of `struct sockaddr' in ), `sa_len' just cannot be zero. Yes, it can not be zero.