qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...


From: Thiemo Seufer
Subject: Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...
Date: Sat, 7 Apr 2007 22:20:47 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

J. Mayer wrote:
> On Sat, 2007-04-07 at 20:10 +0100, Paul Brook wrote:
> > On Saturday 07 April 2007 19:32, J. Mayer wrote:
> > > On Sat, 2007-04-07 at 18:14 +0000, Paul Brook wrote:
> > > > CVSROOT:        /sources/qemu
> > > > Module name:    qemu
> > > > Changes by:     Paul Brook <pbrook>     07/04/07 18:14:41
> > >
> > > The patches in the PowerPC target seem complete nonsense.
> > 
> > Can you give specific examples?
> 
> I'm talking about the CPU code.
> There is NO notion of external IRQ allocation in the PowerPC
> specification.
> IRQ  are completely out of the scope of the CPU emulation so the table
> of 32 void *IRQ pointers is the CPU structure is a complete nonsense.
> Where do you see in the PowerPC specification that those CPU have any
> notion of how the EXTERNAL IRQ controler works ? Where do you see that a
> machine with a PowerPC cannot manage more than 32 IRQ ? Where do you see
> ANY NOTION OF EXTERNAL IRQ MANAGEMENT in the PowerPC specification ?
> EXTERNAL IRQ MANAGEMENT IS NO WAY RELATED WITH CPU ! It's private to
> each IRQ controller. 
> Saying anything else is just completely ignoring how real hardware
> works.
> SO your patch is a complete nonsense and YES IT BREAKS MY WORKS SO IT
> HAS TO BE REVERTED.

So you are saying the old code is similiarily flawed? Why would reverting
to the old version be an improvement then?

> If you don't, I'LL REVERT ALL POWERPC CODE AFFECTED BY THIS PATCH.

I assume you are close to have working code which solves the aforementioned
problems. In that case it might make most sense to stick with the current
version for the moment and replace it with yours as soon as it works.

> > The CHRP code looks a bit broken, but no more so than before I started.
> > 
> > > Furthermore, this kind of patch that break other guys work would likely
> > > to be discussed and not beeing imposed.
> > 
> > It's been mentioned several times on this list (by Fabrice, specifically) 
> > that 
> > this is the way to go.
> 
> I did not received any single mail AT ALL saying "we're going to break
> your code, you can now throw away all the work you're doing". NOT ONE.
> So don't say "it's been discussed several times".

It is a bit hard to figure that out when the existence of such code isn't
known. Btw, I fail to see why it amounts to "throw away all work".
Presumably you could "revert" the offending bits in you local copy and
merge the remaining interface changes.


Thiemo




reply via email to

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