Move the stop for LFCNWRAPSTOP to the point at which writing at segment 0
is really about to commence, since this is what the test expects (and
incidentally what a snapshotting utility wants as well).
More correctly reconstruct the on-disk state at every checkpoint, rather
than relying on the entire state at the point of wrapping to be accurate
(that is only true the first time we wrap). Add a "make abort" target to
make rerunning the test more convenient when it has failed and we're done
analyzing the failure.
where segment 0 is being considered for writing. This allows for automated
checkpoint vailidity scanning, and could be used (in conjunction with the
existing LFCNREWIND) for e.g. snapshot dumps as well.
Include a regression test that does such scanning.
When writing the Ifile, loop through the dirty block list three times to
make sure that the checkpoint is always consistent (the first and second
times the Ifile blocks can cross a segment boundary; not so the third time
unless the segments are very small). Discovered by using the aforementioned
regression test.
really don't think testing the behaviour of open(2) is the subject of that
regression test. Maybe it was a developer regression test? Do I get a
cookie?
in a 64-bit signed integer (thus ensuring that mount_tmpfs handles these
correctly).
Also check that the previous (big) value fails.
This makes this test behave correctly on all platforms (not only 64-bit
ones) after the fix commited to mount_tmpfs.
Those should abort the bpf program.
The test currently fails (out of bound reads silently return zeros), but
succeeds if lo0 is replaced by an Ethernet interface and 127.0.0.1 by an
address reachable through it.
A fix is being worked on.
Approved by martin.
though.
'pseudodev' depends on interface attribute 'hook', but doesn't explicitely
declare locators (which is perfectly allowed, and logical). config(1)
should handle the situation properly.
mrg