You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently qemu-test uses manual tracking of the number of expected tests we want to pass inside the seL4 instance (where the ferros-test based driver is generating output).
It would be nice to have better integration that obviated the need for manually incrementing the expected number of tests to pass. Three approaches spring to mind:
Adjust qemu-test test cases to not actually care about the expected number of tests, and simply relax the targeted-output-regex.
Do some codegen or code-inspection to determine the right target number of tests at build-time.
Increase the sophistication of both the in-seL4 side and the on-host side to actively communicate interactively over some channel (e.g. UART) to establish and check expectations at runtime.
The text was updated successfully, but these errors were encountered:
Presently qemu-test uses manual tracking of the number of expected tests we want to pass inside the seL4 instance (where the ferros-test based driver is generating output).
It would be nice to have better integration that obviated the need for manually incrementing the expected number of tests to pass. Three approaches spring to mind:
The text was updated successfully, but these errors were encountered: