The vether interface simulates a normal Ethernet interface by encapsulating
standard network frames with an Ethernet header, specifically for use as
a member in a bridge(4).
To use vether the administrator needs to configure an address onto the
interface so that packets can be routed to it. An Ethernet header will
be prepended and, if the vether interface is a member of a bridge(4),
the frame will show up there.
Taken from OpenBSD.
The tricky detail here is that the current node from the iteration is
removed if it is no longer needed.
The Lst_FindDatum that has been removed was both inefficient and
misleading since it could never return null, yet there was a null check
for it. The callback API from Lst_ForEachUntil would have required to
define a custom struct for passing this parameter to the callback
function, in addition to the parent node.
Inlining the whole Lst_ForEach and passing the list node as a parameter
is much more obvious.
This protects against very simple memory allocation bugs such as
migrating Lst_ForEachUntil to Lst_ForEach without remembering that
Lst_ForEachUntil can handle the situation where the current list node is
removed from the list, but Lst_ForEach cannot. This happens in
Make_ExpandUse, for example.
Before August 2020, the Lst library passed null pointers through. This
was a confusing design pattern that has been removed since. Now the Lst
functions fail fast on null pointers.
The 'targets' list is one of the few places where there is indeed an
optional list that may sometimes be null. Back then, there was not
enough inline documentation to understand when the targets list was null
and when it wasn't.
Now that the documentation is there, the redundant and thereby
misleading null checks are no longer useful.
Printing a node does not modify the structure of the node, therefore the
additional housekeeping of Lst_ForEachUntil is not needed here.
Inlining the callback function also removes a lot of pointer stuff that
is more difficult to read than necessary.
This avoids the extra local function and a few conversions to void
pointers, to gain additional type safety.
The code in Compat_RunCommand does not modify gn->commands structurally,
therefore it does not need the extra complexity of Lst_ForEachUntil. It
does have access to a list node to exactly this list. This list node is
only used to set the command to NULL after processing it, not for
removing the node from the list.
If any member is LINK_STATE_UP then it's LINK_STATE_UP.
Otherwise if any member is LINK_STATE_UNKNOWN then it's LINK_STATE_UNKNOWN.
Otherwise it's LINK_STATE_DOWN.
- Bug fixes to gmp_snprintf, conversion to double, mpz_powm,
and mpf_set_str.
- New functions for factorial, primorial, fibonacci, mpz_2fac_ui,
and mpz_mfac_uiui.
- MIPS r6 cores are now supported.
- Various speeds ups.
does not use mknative.common yet, so always updates files and does
not mark them with NetBSD rcsid. (not a regression from the manual
version at least.)
used to before.
while it uses less total lines of code and looks less ugly,
the merged crash+ddb code here is less correct and harder to
follow for the kernel path.
There is a crucial difference between these functions, in that
Lst_ForEachUntil can cope with a few concurrent modifications while
iterating over the list. This is something that Lst_ForEach doesn't do.
This difference led to a crash very early in NetBSD's build.sh.
These functions made the code larger than necessary. The prev and next
fields are published intentionally since navigating in a doubly-linked
list is simple to do and there is no need to wrap this in a layer of
function calls, not even syntactically. (On the execution level, the
function calls had been inlined anyway.)
The 3 callers of this function passed different flags, and these flags
led to code paths that almost did not overlap.
It's a bit strange that GCC 5 didn't get that, and even marking the
function as inline did not produce much smaller code, even though the
conditions inside that function were obviously constant. Clang 9 did a
better job here.
But even for human readers, inlining the function and then throwing away
the dead code leads to much easier code.
This pattern of squeezing completely different code into a single
function has already occurred in a different part of make, though I
don't remember where exactly.
The previous API had complicated rules for the cases in which the single
function returned NULL or what it did. The flags for that function were
confusing since passing TARG_NOHASH would create a new node even though
TARG_CREATE was not included in that bit mask.
Splitting the function into 3 separate functions avoids this confusion.
It also reveals several places where the complicated API led to
unreachable code. Such code has been removed.
Link state changes are not dependant on the interface being up, but we also
need to guard against more link state changes being scheduled when the
interface is being detached.
We do this by clearing the link queue but keeping if_link_sheduled = true.
We can check for this in both if_link_state_change() and
if_link_state_change_work() to abort early as there is no point in doing
anything if the interface is being detached because if_down() is called
in if_detach() after the workqueue has been drained to the same overall
effect.
