qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.


From: Artyom Tarasenko
Subject: Re: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.
Date: Wed, 17 Feb 2010 10:24:58 +0100

2010/2/16 Rob Landley <address@hidden>:
> On Tuesday 16 February 2010 03:31:16 Alexander Graf wrote:
>> On 16.02.2010, at 01:52, Rob Landley wrote:
>> If swapping the parameter was the right solution I would've submitted a
>> patch long ago :-). Unfortunately it's not as easy.
>
> I agree that making a single controller handle four drives is a _better_ fix.
> (Somebody said that current Linux kernels notice the DMA failure and fall back
> to PIO-ing the drive, or some such.  I take it that MacOS doesn't?)
>
> I just want it fixed, and if that's the direction qemu would prefer to go on
> that issue, I'd like to encourage that in any way I can.  I just don' t know
> how...
>
>> But the inlining is
>> really only about simple commenting. It's a lot nicer to have context when
>> you say "this doesn't make sense" or so :-).
>
> Understood.  I can do that here in future.
>
>> Either way - it's good to see someone interested in the topic actually
>> sending patches. Reviewing and commenting doesn't mean I don't like what
>> you're doing. In this case it just means I'm pretty sure it doesn't solve
>> the problem, but only the symptoms.
>
> Thanks.  I'm interested, but overwhelmed.
>
> My FWL project is an attempt to make as many different targets as possible 
> work
> the same way, generally under QEMU.  This lets me regression test Linux and
> uClibc and busybox and such across all of 'em.  (Eventually from a nightly
> cron job rebuilding everything from scratch on an 8-way server, with automatic
> "git bisect" telling me what commit broke it.)
>
> So far I've got arm, mips, powerpc, and x86/x86-64 building little native
> development environments, which can then natively build dropbear and strace
> inside qemu (optionally calling out to the cross compiler via distcc).  Each
> of those has a working CPU emulation (with mmu) on a board with a network
> card, three disks, at least 256 megs of memory, serial console, and clock
> chip.
>
> I've also got a bunch of "sort of working, but not well enough to run builds
> natively under" targets on top of that (arm big endian, sh4, sparc...)

What's not well enough on sparc?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]