I had very conveniently assumed that the maximum number number of segments when
doing was 3 it was an arbitrary choice, also it felt covenient to use 3
segments when doing the tests in a R-B Tree. The segment count was set using the
macro VM_PHYSSEG_MAX before the beginning of the tests.
But it was not until Cherry (cherry@) noticed the number of failed tests started
piling up faster than a deck of cards falling from a collapsing house of cards,
when the value of VM_PHYSSEG_MAX was set to values less than 3, the tests
were working as expected for values greater than 3. The value of 1 and
2 were also important to reflect on how a system with just 1 or 2
segment(s) will fare with with the upcoming changes using a R-B Tree.
So we both sat down and started to review the code, and there were multiple
tests where we implicitly assumed there are always 3 segments for example
uvm_physseg_get_next test where we iterate over 3 segements to verify the
correctness of the function or uvm_physseg_unplug which can only be tested
under the condition that there is more than 1 segment.
So with careful usage of #if, #endif and some clever uses of the test
functions atf_tc_expect_signal() and atf_expect_fail() we were able to
segregate code that runs under the edge cases when VM_PHYSSEG_MAX is 1 or
2.
One of the interesting uses cases of “expecting” failure we came across was to
indicate that a feature is NOT available / implemented.
So lesson learned, “NEVER assume things”, but we all know that I am going to end
up assuming stuff again.