[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 05.01.2011, at 13:07, Rob Landley wrote:

> On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote:
>>>> I have this very issue with s390. The only host to run (and compile)
>>>> this on is an s390. And few people have those. So it breaks from time to
>>>> time.
>>> 
>>> I have some pages bookmarked hinting how to get S390 Linux to boot under
>>> hercules, the same way I have instructions for running m68k under Aranym.
>>> But in general, if QEMU doesn't support it I have a hard time making
>>> myself care...
>> 
>> Few people jump through the hoops to run an emulator to compile and run
>> qemu inside then when they only want to verify if their patches break
>> something. The general philosophy I've seen is that the best we can expect
>> is a "does ./configure && make break on your x86_64 box?".
> 
> If you're talking about running qemu on a non-x86 host, I don't do that.  But 
> if you're talking about running non-x86 code on qemu, my project's motto is 
> "we cross compile so you don't have to".  The thing is designed so you grab a 
> tarball and go "./run-emulator.sh" to get a shell prompt in your emulated 
> environment, with full development tools.  If you go "./dev-environment.sh" 
> instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can 
> wget and build fairly large packages.
> 
> I've built the whole of Linux From Scratch 6.7 inside this this, on a couple 
> different platforms.  (Still debugging powerpc and mips, probably uClibc 
> issues.  Less spare time than I used to have...)
> 
> In theory I could do the same with qemu itself, just like any other software 
> package.  If you feed it just one architecture in a --target-list it 
> shouldn't 
> take _too_ long to build.  But in practice running the result would be too 
> slow to do more than boot to a shell prompt and demonstrate that it worked.

Yeah, don't worry. My point was that anything that doesn't build and run on x86 
hosts has little chance of getting test coverage.

> 
>>> I have been know to test out of tree architecture patches, though.  I
>>> only ever got sh4 to work by patching qemu, for example.
>> 
>> I really dislike out-of-tree.
> 
> I can't stand 'em, but I don't control what gets merged into most projects.

The main issue is that it takes time and effort to get stuff upstream - and 
it's good that way. There are people out there who are great programmers, but 
unfortunately don't have the patience to go through an upstream merging cleanup 
process.

> 
>> As soon as an architecture runs publicly
>> available code, it should get upstream, so others can benefit from it.
> 
> Entirely agreed.  I've been waiting for any of the m68k improvements to QEMU 
> (to run more than just coldfire) work to get merged for a long time.  And I 
> have a todo item to look at https://github.com/uli/qemu-s390 also...

I'm currently working on the s390 parts, so no worries. I have a cleaned up 
tree and partially working system emulation already.


Alex