On 12/29/2011 07:22 PM, Peter Maydell wrote: > On 29 December 2011 16:36, Avi Kivity <a...@redhat.com> wrote: > > Yes; but using Linux limits you to what it exposes (of course Linux > > exposes quite a lot, so that's mostly a non issue; but we'll have > > counterexamples). > > Actually IME Linux is pretty conservative about how it uses devices. > A lot of the ARM device models have gaping holes in their emulation > which we've never needed to fix because Linux simply doesn't use > those features (eg the PL080 DMA controller which doesn't actually > implement DMA!)
We were discussing fingerprinting, not actually driving the device. For that, I think we're all agreed that qtest is vastly superior to using an OS driver. > I think for devices what would be particularly useful would be > if you can write a (simple) test for something at the register > level, which generates an image which you can run on the real > hardware as well as on QEMU. Then you can confirm that your test > case is correct. Otherwise the tests are just going to bake in the > same assumptions/misconceptions about what the hardware does as > the QEMU model. That is exactly qtest. > My guess is that a serious attempt at tests covering all the > functionality of a device is probably approximately doubling > the effort required for a device model, incidentally. A > half-hearted attempt probably doesn't buy you much over > automating "boot the guest OS and prod its driver". Agreed. -- error compiling committee.c: too many arguments to function
