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

[Rob Landley]

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...)  I 
occasionally make puppy eyes at the m68k guys to see if something beyond 
coldfire is likely to go in, I've even poked at alpha a couple times (but gcc 
dying with an internal compiler error on a hardware platform end-of-lifed a 
decade ago isn't high on my todo list), I should re-check cris to see if it's 
grown any non-toy boards yet, getting S-360 working is on my todo list...

Unfortunately, what this means is I haven't got the bandwidth to become an 
expert on each of these targets.  I'm reasonably good at flailing about wildly, 
but I'm totally out of my depth most of the time and I know it.

Often I have to come up with The Wrong Fix(tm):

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html

And then the people who know what's going on do a proper fix:

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079436.html

Or in the case of some maintainers, decline to do so because they honestly 
don't care if anybody else but their employer ever actually uses the thing, 
thus I'm stuck carrying The Wrong Fix as a patch:

  http://www.spinics.net/lists/linux-sh/msg04146.html

I hate it when that happens...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds