On Fri, Jan 20, 2017 at 01:26:11PM +1000, Martin Pieuchot wrote:
> On 20/01/17(Fri) 03:04, Claudio Jeker wrote:
> > I want to use art routing tables with pf addrs and not sockaddrs.
> > Art itself does not care but the API requires sockaddr pointers in some
> > places. This changes those to void *.
work on making log.c similar in all daemons:
reduce the (mostly whitespace) differences so that log.c's can be
diffed easily. disclaimer change ok henning@.
diff --git usr.sbin/ypldap/ldapclient.c usr.sbin/ypldap/ldapclient.c
index 02cd4616acf..3a8fb90d33e 100644
--- usr.sbin/ypldap/ldapclie
work on making log.c similar in all daemons:
move daemon-local functions into new logmsg.c, and reduce
the (mostly whitespace) differences so that log.c's can be diffed easily.
removal of log_rtmsg() approved by claudio@
diff --git usr.sbin/ldpctl/Makefile usr.sbin/ldpctl/Makefile
in
work on making log.c similar in all daemons:
move daemon-local functions into new logmsg.c, and reduce
the (mostly whitespace) differences so that log.c's can be diffed easily.
diff --git usr.sbin/ldapctl/Makefile usr.sbin/ldapctl/Makefile
index 50befd7..682b791 100644
--- usr.sbin/ldapctl/M
On 20/01/17(Fri) 03:04, Claudio Jeker wrote:
> I want to use art routing tables with pf addrs and not sockaddrs.
> Art itself does not care but the API requires sockaddr pointers in some
> places. This changes those to void *.
>
> OK? This is step 2 to a new pf_table backend.
What's the problem w
Currently, clang generates references to __guard_local as if it had
default visibility. This is non-optimal on various archs, so lets tell
clang that __guard_local is hidden.
I *think* this is the right way to tell clang this and it seems to work on
amd64, generating
movq__guard_l
I want to use art routing tables with pf addrs and not sockaddrs.
Art itself does not care but the API requires sockaddr pointers in some
places. This changes those to void *.
OK? This is step 2 to a new pf_table backend.
--
:wq Claudio
Index: net/art.c
==
Diff below enables the NET_LOCK(), again.
What's new?
- The lock ordering problem with fdplock() should now be fixed. It is
also documented, fdplock() should be taken first if both locks are
needed.
- Page faults involving NFS, or any other code path already holding the
NET_LOCK(),
pfsockaddr_union needs to die. This fixes two of the uses of it and the
pf_table code will follow later. For bridge we just move the definition
and in pfsync we can actually use the one from ip_ipsp.h since it is used
for that.
OK?
--
:wq Claudio
Index: net/if_bridge.h
==
this has the ifq count the statistics kept for output packets that
we currently count on an ifnet.
unlike the ifnet stats, these are all maintained by the ifq as a
matter of course except for the output errors counter. this means
drivers wont have to account for outgoing packets like they do now,
I sent this diff out some time ago and would really like to get this in.
This is one step on makeing rtsock.c less of a hornets nest.
This reduces the side effects in route_output and simplifies some other
bits as well. For example route_input is less variadic and simpler.
Anyone couragous enough
this is an implementation of a heap data structure, specifically a pairing heap.
it is implemented like the RB trees in that it can be used to
organise arbitrary structs with arbitrary compare functions. eg,
we could queue tasks on a heap and order them by an execution
deadline.
ok?
Index: share
Turns out that the NET_LOCK() related hang reported by many is a
deadlock. One way to prevent it is to ensure that fdplock() is
always taken before the NET_LOCK() when both have to been hold.
This generates the diff below.
Comments, ok?
Index: kern/uipc_socket.c
On 2017 Jan 19 (Thu) at 06:26:25 +0100 (+0100), Peter Hessler wrote:
:On 2016 Dec 17 (Sat) at 14:05:40 +0100 (+0100), Peter Hessler wrote:
::On 2016 Sep 30 (Fri) at 10:16:19 +0200 (+0200), Peter Hessler wrote:
:::This diff makes route get and route monitor work. sockaddr_bfd is so we
:::can play l
14 matches
Mail list logo
