Fixup rust-1.98 riscv64 bootstrap used to build rust-1.99
Somehow the previous one was broken with what looked like
a non-reproducible getxecpath-related error.
ok semarie@ (maintainer)
Rework how rtables are allocated and reduce use of RT_TABLEID_MAX
Currently rtables use multiple arrays to do lookups and the reallocation
logic is complex and not race free. Replace all of this with a much
simpler lookup that is inspired by the if_idxmap used to map interfaces.
Use a single SMR backed object that contains the size and the array
of rtable pointers. This array can only grow and objects referenced
from the array are never freed. So the life-cycle becomes much simpler.
To make this work struct rtable needs to include all information
contained in a rtable / rdomain. This includes the sourceaddr per table,
the loopback interface index, the rtable to rdomain mapping and in the
future also the multicast router data. Once a struct rtable is allocated
it is never freed.
At the same time reduce the usage of RT_TABLEID_MAX and have rtable_exists
do the check against the real limit. In general code like SIOCSLIFPHYRTABLE
only need to verify that the rdomainid is non-negative and the upper limit
[3 lines not shown]
During DVACT_SUSPEND, after ensuring the soft state was good, this
would try to reset the chip, then keep trying to restart it, pretty
much iteratively, and would reach into sleeping logic. This is obviously
incorrect and not neccessary. Unfortunately this diff is since noone
has showed up with one of these devices in years.
INCOMPATIBLE update to lmdb-1.0.2
Since the database format used by LMDB 0.9 and 1.0 are not compatible,
and upstream provides no compat code and no explicit warning message:
- ship mdb_dump-0.9 from the LMDB-0.9 package
- add tests in the port that mdb_load from 1.0 can restore a test
database generated with LMDB-0.9
- warn users and tell them the basic steps to migrate a DB
No @ask-update, you've been warned! A pending knot-3.6.2 update
ought to make things easier for users of that port.
General input from sthen & espie, ok kmos@ rsadowski@, "reads ok" otto@