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