Mark,
Thanks for engaging me on this rewrite.
I built an automated harness for each OS reference disk. It mounts the
disk as a CD-ROM, creates a blank HDD, and uses pyte and regex to drive
installation, reboot, and login.
Multiple HP-UX versions, Debian Linux, and NetBSD 9.4/10.1 all boot,
install, reboot, and run successfully. That provides strong high-level
confidence, though it does not rule out bugs.
I have run the tests hundreds of times, both sequentially and
concurrently, to expose timing or race issues. The full suite takes
about an hour.
I do not plan to distribute the images or tests because of licensing
concerns and required preprocessing.
Thanks for mentioning those debug flags. I'm not using them now.
It wasn't lost on me that I wasn't including any relevant executable
tests. When you say functional tests, are you talking specifically
/tests/functional/hppa? So similar to test_cdboot.py, changing machine
type to -M 715, downloadable asset/image? This does bring up where we
point this to? Like is archive.org acceptable reference? Whether it's my
harness or the other, we still have a few challenges.
Finally, I overstated the not bootable case, and this should be not be
problematic. Linux/Debian and Netbsd will work at ANY patch level, but
HP-UX (which to be clear doesn't work at all on the released existing
710 model right now) will only start functioning once everything is in
place.
Thanks,
Keith
On 7/14/2026 5:43 PM, Mark Cave-Ayland wrote:
Hi Keith,
Thank you for your contribution to QEMU. I found myself in a similar
situation a couple of years back when I ended up reworking a large part
of the ESP SCSI emulation to fix some fairly obscure edge cases booting
Classic MacOS, so I understand how difficult a task this can be.
If you would like to take a look at my series and cover letter then you
can find it at https://patchew.org/QEMU/20240112125420.514425-1-
[email protected]/, but I've summarised some thoughts below
based upon my experience:
- I focused on using a small set of reference images and made sure
they would
boot upon every commit. This was really helpful as sometimes even a
subtle code
movement would cause something to break unexpectedly, and helped me
to find
extra edge cases I had missed.
- Keep changes to individual devices in separate commits where
possible, and also
the same goes for refactoring/renaming commits and changes to the
device
logic/functionality. Often these commits can be merged earlier than
later
patches in the series where the reviewer may have more questions.
- Not all reviewers are familiar with SCSI, so writing a good cover
letter
explaining each part of the series will help reviewers understand
the changes
during review.
- Run your local tests in both a normal and --enable-debug build, and
also with
asan (--enable-asan) to catch any memory errors
- Adding a functional test if possible would help prevent future
regressions.
Similarly for reviewers I should note that the LSI SCRIPTS engine is
quite complex: in effect it is almost like a separate processor
executing its own programs (SCRIPTS) to perform I/O.
As I remarked in my ESP series cover letter, it is almost impossible for
someone to perform a comprehensive review without being very familiar
with the controller and its datasheet, so when attempting to review the
series, I would probably focus on looking how it compares with the
existing lsi53c895a code which is mature and working well. For me this
would mean that adding notes explaining any unusual differences between
the two devices on the commit message would be extremely helpful during
review.
You mentioned above the problem with implementing new helpers causing
boot to break between patches 5 and 8: is it possible to bring in the
new logic/helpers a phase at a time (like I did with ESP) to help keep
things working? Perhaps a temporary lock to enable the async helpers to
work in a sync manner temporarily could also help?
ATB,
Mark.
