over EFence and also hopefully smaller memory overhead, but sadly it's non-free
for commercial use).
If the DMALLOC_OPTIONS environment variable is not set, switch on `reasonable'
checks by default.
Also introduced mb_allocz() for cleared mb_alloc().
The new kernel syncer is cleanly split between generic UNIX module
and OS dependent submodules:
- krt.c (the generic part)
- krt-iface (low-level functions for interface handling)
- krt-scan (low-level functions for routing table scanning)
- krt-set (low-level functions for setting of kernel routes)
krt-set and krt-iface are common for all BSD-like Unices, krt-scan is heavily
system dependent (most Unices require /dev/kmem parsing, Linux uses /proc),
Netlink substitues all three modules.
We expect each UNIX port supports kernel routing table scanning, kernel
interface table scanning, kernel route manipulation and possibly also
asynchronous event notifications (new route, interface state change;
not implemented yet) and build the KRT protocol on the top of these
primitive operations.
o Introduced if_find_by_index()
o Recognizing two types of interface updates: full update (starting with
if_start_update(), ending with if_end_update(), guaranteed to see
all existing interfaces) and a partial update (only if_update(),
usually due to asynchronous interface notifications).
o Introduced IF_LINK_UP flag corresponding to real link state.
o Allowed addressless interfaces.
o IF_UP is now automatically calculated and set iff the interface
is administratively up, has link up and has an IP address assigned.
It may be IF_IGNORED, though (as in case of the loopback).
o Any changes which include up/down transition are considered small
enough to not provoke artificial upping and downing of the interface.
o When an interface disappears (i.e., it wasn't seen in the last scan),
we announce this change only once.
o IF_LOOPBACK implies IF_IGNORE.
nodes having no routes attached. Such cleanup must be done from event handler
since most functions manipulating the routing tables expect network entries
won't disappear from under their hands and it's also probably faster when
done asynchronously.
of various callbacks.
Events are just another resource type objects (thus automatically freed
and unlinked when the protocol using them shuts down). Each event can
be linked in at most one event list. For most purposes, just use the
global event list handled by the following functions:
ev_schedule Schedule event to be called at the next event
scheduling point. If the event was already
scheduled, it's just re-linked to the end of the list.
ev_postpone Postpone an already scheduled event, so that it
won't get called. Postponed events can be scheduled
again by ev_schedule().
You can also create custom event lists to build your own synchronization
primitives. Just use:
ev_init_list to initialize an event list
ev_enqueue to schedule event on specified event list
ev_postpone works as well for custom lists
ev_run_list to run all events on your custom list
ev_run to run a specific event and dequeue it
