This test still fails (as does another using tap interfaces) ...
tc-se:rump.ifconfig: clone_command: Device not configured
tc-se:rump.ifconfig: exec_matches: Device not configured
Something is wrong with rumpnet_tap ...
Unfortunately only the source code for the compiler is present for that
release. The v2 archive is missing the manuals & only contains a some of the
commands.
Switch to v3 and reference manual category eight, as per r1.32 of
src/bin/ps/ps.1 from OpenBSD.
Heads up from Ingo Schwarze.
building was completed only to discover that within there lay havoc.
On the second day all just groaned and moaned, and it must be someone
else's problen.
On the third day, St. Martin stepped in and traced the culprit, which
provided inspiration, and a correction was made.
Forevermore all were agog at just how such a trivial thing could do
so much damage...
OK... to be a little less vague. The loopback interface is a truly
"special" thing, and rump knew that - and treated it very specially.
Unfortunately, when the loopback interface is changed, and rump does
not keep up, bad things happen.
This (overall) might, or might not, be the correct fix - but for now
it appears to work. If someone, sometime, finds a better way to
deal with the issues of the loopback interfaces true majesty, feel
free to revert this and do it another way.
it actually (used to) behave when it was incorrect... Aside from
a possible EPERM (which is not tested) the only error possible from
mlock() is ENOMEM. POSIX also allows EINVAL if the address is not
page aligned and the implementation does not round down to the previous
page boundary, but NetBSD does.
The kernel was recently fixed to return the correct errors for mlock()
so now we really need the test to be checking them, and not expecting
the incorrect errno values that the kernel used to return.
Same for munlock() - there ENOMEM is the only possible error, again,
EINVAL cannot happen as the kernel rounds to page boundaries.
For munlock() the kernel has not yet been corrected (that is coming
real soon...) and one of the munlock() tests will currently fail
(as of the time this commit is made, hopefully not for much longer)
as it should - it is indicating a kernel bug.
Note that NetBSD mlock(2) talks about EINVAL for cases where the length
parameter is negative ... but that is a size_t - good luck having that
ever occur (the man page will soon be corrected as well.)
