On 8 March 2018 at 10:26, Thomas Huth <th...@redhat.com> wrote: > On 08.03.2018 11:07, Peter Maydell wrote: >> Are we sure this is the entire list of machines that use this? > > Yes. The problem only occurs for boards that are using > block_default_type = IF_SCSI. > > $ grep -rl IF_SCSI hw/ > hw/arm/versatilepb.c > hw/arm/realview.c > hw/mips/mips_jazz.c > hw/ppc/prep.c > hw/ppc/spapr.c > hw/scsi/scsi-bus.c > hw/sparc/sun4m.c > hw/hppa/machine.c > > versatilepb, realview and the hppa machine were already using > lsi53c895a_create() that takes care of this already. spapr is properly > using scsi_bus_legacy_handle_cmdline() in spapr_vscsi_create(). And for > jazz, prep and sun4m, I sent the patches to the list yesterday.
Cool. >> Can we in general try to avoid removing generic code features >> until we've checked and fixed everything that relies on them? x86 pc >> is not the only system we support... > > Sure. You know, I'm a ppc / s390x guy, so I am very aware of other > platforms, too. In this case it was just a bad misunderstanding - I did > not expect that the code would still be used on other platforms, too. > Sorry for that. Sorry for being grumpy -- I should have skipped sending that mail til I'd had some more coffee. > The problem is rather that we still need more automatic regression tests > for stuff like this. I already have got something in mind for a new > qtest: If "mkisofs" or "genisoimage" is available, we could create a > boot CD-ROM automatically using the boot code from tests/boot-sector.c. > Then the test could try to boot from that CD-ROM to check whether > "--cdrom" is still working as expected. What do you think, does that > sound reasonable? That's probably a good plan, though it wouldn't be able to cover boards like versatile/realview that can't boot from a cdrom. thanks -- PMM
