[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
From: |
Alexander Graf |
Subject: |
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation |
Date: |
Wed, 5 Jan 2011 13:31:01 +0100 |
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