On Wed, Apr 18, 2012 at 20:35, Anthony Liguori <aligu...@us.ibm.com> wrote: > On 04/18/2012 03:28 PM, Blue Swirl wrote: >> >> On Tue, Apr 17, 2012 at 21:33, Anthony Liguori<aligu...@us.ibm.com> >> wrote: >>> >>> On 04/17/2012 03:59 PM, Peter Maydell wrote: >>>> >>>> >>>> On 17 April 2012 21:43, Blue Swirl<blauwir...@gmail.com> wrote: >>>>> >>>>> >>>>> On Tue, Apr 17, 2012 at 20:31, Peter Maydell<peter.mayd...@linaro.org> >>>>> wrote: >>>>>> >>>>>> >>>>>> Well, it could. But we should make that decision based on whether it >>>>>> makes sense and has a use case for actual users of the board, not >>>>>> because we're trying to get away with not having a setup that lets >>>>>> us properly unit test devices. >>>>> >>>>> >>>>> >>>>> I disagree. I see many benefits in qtest and very little downsides in >>>>> changes like these. >>>>> >>>>> qtest is a tool to let developers test the changes they make to >>>>> devices, so breakages shouldn't be so common. This should improve the >>>>> development process in QEMU tremendously. >>>> >>>> >>>> >>>> I'm entirely in favour of having a decent testing framework so we >>>> can easily write unit tests for device models. What I don't understand >>>> is why a developer only unit testing tool seems to require changes >>>> to user visible behaviour across dozens of board models. Something >>>> is wrong in its design somewhere, and I think that's what I'm >>>> objecting to as much as to the specific detail of what's being >>>> changed in this patch. >>> >>> >>> >>> <rant> >>> >>> Kernel loading is a hack. I'll go out on a limb and say that most >>> non-x86 >>> boards are doing it completely wrong. Messing around with CPU state has >>> no >>> business in machine init. It creates horrible dependencies about RAM >>> initialization order and problems for reset/live migration. >>> >>> The kernel should be presented as a virtual device (an emulated flash or >>> whatever) and there should be firmware that loads the kernel >>> appropriately. >>> Then we wouldn't need changes like this in the first place. >> >> >> BIOS is no hack, it is not used by qtest, MIPS refuses to start without >> one and >> we don't have any. > > > So how does one test MIPS system emulation?
Maybe there are BIOS files which are not redistributable. > > Regards, > > Anthony Liguori > > >> >>> >>> </rant> >>> >>> But now that that's out of my system, I don't think we should change >>> every >>> board that's doing direct kernel loading. But this is why we need to >>> make a >>> change like this. The boards are "wrong in its design somewhere". >>> >>> >>>> (And I don't want us to add lots of tests >>>> and/or changes to the code before we fix whatever the problem is.) >>> >>> >>> >>> If you'd like to change all of the boards to behave in a way that's >>> sensibly >>> similar to how actual hardware would work, that's fine by me :-) >>> >>> >>> Regards, >>> >>> Anthony Liguori >>> >>>> -- PMM >>>> >>> >> >