Add LM3S6965 QEMU target for testsuite; add to CI

[KoviRobi]

Seems like 3816321 has introduced a failure

…/lilos/testsuite/lm3s6965 (3816321) zsh
❯ cargo r -F exit
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -s -kernel target/thumbv7m-none-eabi/debug/lilos-testsuite-lm3s6965`
Timer with period zero, disabling
test_yield_cpu... OK
test_other_tasks_started... OK
test_clock_advancing... OK
test_sleep_until_basic... OK
test_sleep_until_multi... OK
test_with_deadline_actively_polled... OK
test_with_deadline_blocking... OK
test_notify... OK
list::test_node_basics... OK
list::test_list_basics... OK
list::test_insert_and_wait... OK
list::test_insert_and_wait_with_cleanup... panicked at /home/rmk35/programming/rust/lilos/testsuite/src/list.rs:88:5:
assertion failed: list.wake_one()

whereas it works with 15a82a8. I could rebase onto 15a82a8 instead and then the MR pipeline would work, but the main one after merge would of course not work.

If I understand correctly, the test is now xfail as
3816321#diff-edfc99d7877e9698c7d88566912259dc60ec7a2ef520c505dd37b0fc1016cd2bR453 the node is not attached until polled so

lilos/testsuite/src/list.rs

Lines 83 to 89 in 3816321

	// Try again, this time with detachin'
	let fut = list.insert_and_wait_with_cleanup(
	node.as_mut(),
	|| cleanup_called.set(true),
	);
	assert!(list.wake_one());
	assert!(!cleanup_called.get()); // not yet

wake_one will not wake any. Though not sure if the way forward is to remove the second part of the test or rewrite.

The 3816321 is a major change, I think, as the cleanup now never can happen

lilos/os/src/list.rs

Lines 411 to 415 in 3816321

	/// The `cleanup` action is performed in only one circumstance:
	///
	/// 1. `node` has been detached by some other code,
	/// 2. The returned `Future` has not yet been polled, and
	/// 3. It is being dropped.

and now points 1. and 2. are mutually exclusive, as for the node to be detached (1), it needs to be attached first, which is only done by the first poll (2).

I think the mutex definitely needs looking at again, that seems to be the only user of insert_and_wait_with_cleanup. I haven't fully wrapped my head around it for now, and will go to bed. Maybe I will have a dream where it will all become clear, though I suspect it's just that this stuff is inherently complex 😅

[cbiffle]

I've fixed the test failure you noticed in b8516cc. Thanks for pointing that out.

I've historically been very suspicious of QEMU for testing because QEMU is, to put it simply, wrong. Its Cortex-M device models are sufficiently wrong that Hubris (my day-job operating system) can't boot.

However, lilos relies on a lot less of the ARMv7-M architecture details (and in particular, relies on fewer details of the interrupt controller and systick). So maybe this is worth a shot.

Let me get this rebased.

[cbiffle]

Alright, I've made some changes:

• Changed the authorship credit on the lm3s testsuite to point to you, since I didn't really do anything to make that happen. :-)
• Rebased on my recent changes heading toward 1.0.0
• Simplified the feature handling, since the lm3s is an ancient M3 target that mostly only appears in QEMU -- we can set the exit feature by default, and then we don't have to special-case that testsuite.
• Rearranged how this fits into CI, since I've changed some details of CI since you wrote this.