Paolo Bonzini <pbonz...@redhat.com> writes: > Il 05/10/2012 15:58, Anthony Liguori ha scritto: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >>> Il 05/10/2012 14:43, Jan Kiszka ha scritto: >>>>>>>> This "| 1" might be the problem. Anthony, are you relying on it in >>>>>>>> qemu-test and/or can you work out the changes if we use just >>>>>>>> "exit(val)"? >>>>>> >>>>>> The reason for ' | 1' was to make sure that the guest couldn't trigger >>>>>> an exit(0). >>>>>> >>>>>> If there's a compelling reason to drop '| 1', I can adjust my tests >>>>>> accordingly. >>>> assert(val); (or hw_error) >>>> exit(val); >>>> >>>> I would suggest. >>> >>> I think what the kvm_unittests want is exactly to trigger an exit(0). >>> Why did you rule it out? >> >> Mainly to differientiate between an open coded exit(0)/exit(1) and >> something triggered by the unit test. >> >> The problem I tried to cope with was: >> >> anthony@titi:~/git/qemu$ grep 'exit([01])' hw/*.c | wc -l >> 249 > > Understood. The right solution is of course to fix hw/*.c.
I don't think it's an awful thing for test harnesses to just use a reserved range of exit reasons. Should be easy enough to change kvm-unittests, no? Regards, Anthony Liguori > > Let's start with exit(0). > > hw/eeprom93xx.c: exit(0); <--- should be hw_error > hw/pci.c: exit(0); <--- move to qemu_show_nic_models > hw/spapr.c: exit(0); <--- should be exit(1) !! > > For exit(1), many of them should become hw_error, especially those in > this files: > > hw/bonito.c > hw/ivshmem.c > hw/lsi53c895a.c > hw/pci.c > hw/pl022.c > hw/pl061.c > hw/pl110.c > hw/qxl.c > hw/smbus.c > hw/ssd0303.c > hw/ssi-sd.c > hw/stellaris_enet.c > hw/virtio-blk.c > hw/virtio.c > hw/virtio-net.c > hw/virtio-scsi.c > > Any takers? > > Paolo
