CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/04/08 06:29:06
Modified files:
linux-user : main.c
Log message:
Sparc32/64 CPU selection for user emulator
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qem
Add ARM EABI syscall interface support for pread/pwrite. Patch in the=20
atachement.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
diff --git a/qemu.spec b/qemu.spec
diff --git a/qemu/linux-user/syscall.c b/qe
Hi,
I can only fix the code that I have access to.
IMHO your request that I revert changes because they allegedly break code that
noone else has access to is unreasonable. My changes are a significant
cleanup to qemu internals.
However if there is agreement from other maintainers I will rev
J. Mayer wrote:
[snip]
> To give you an real example why arbitrary limits are not acceptable AT
> ALL: I know an embedded Mips device (widely used !) with 2 CPU, 8 PIC
> and about 500 IRQ sources.
Care to tell which one this is?
> How can you even pretend add a limited
> structure in the CPUState
On Sun, 2007-04-08 at 00:13 +0100, Paul Brook wrote:
> On Saturday 07 April 2007 23:18, J. Mayer wrote:
> > It seems that you don't figure out how real hardware works AT ALL.
> > IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO
> > ONE IRQ CONTROLLER. IRQ management, once aga
On Saturday 07 April 2007 23:18, J. Mayer wrote:
> It seems that you don't figure out how real hardware works AT ALL.
> IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO
> ONE IRQ CONTROLLER. IRQ management, once again, is completelly specific
> to an IRQ controller technology
J. Mayer wrote:
[snip]
> > > SO your patch is a complete nonsense and YES IT BREAKS MY WORKS SO IT
> > > HAS TO BE REVERTED.
> >
> > I can only fix the code that I have access to.
>
> You broke the commited code And you also completely break any new
> development for the PowerPC target as mos
It seems that you don't figure out how real hardware works AT ALL.
IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO
ONE IRQ CONTROLLER. IRQ management, once again, is completelly specific
to an IRQ controller technology and absolutely not related to the CPU
you may use on the
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 +, Paul Brook wrote:
> > > > CVSROOT:/sources/qemu
> > > > Module name:qemu
> > > > Changes by: Paul Brook 07/04/07
Hi Eduardo,
I really appreciate your help but there is a small think that I need to ask
you.
In target-i386/translate.c, there are many variants of mov i.e.
case 0x89: /* mov Gv, Ev */
case 0xc7: /* mov Ev, Iv */
case 0x8b: /* mov Ev, Gv */
case 0x8e: /* mov seg, Gv */
which one do you think wi
On Saturday 07 April 2007 21:28, 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 +, Paul Brook wrote:
> > > > CVSROOT:/sources/qemu
> > > > Module name:qemu
> > > > Changes
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 +, Paul Brook wrote:
> > > CVSROOT: /sources/qemu
> > > Module name: qemu
> > > Changes by: Paul Brook 07/04/07 18:14:41
> >
> > The patches i
> Sparc seems undamaged, devices using IRQs work as before. SMP BogoMIPS gets
> calculated and that needs per-CPU IRQs.
For the record I tested win2k, knoppix and x86 debian, mips test image, sparc
debian installer, arm test image, and a preinstalled ARM linux.
I didn't test ppc (other than that
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/04/07 19:33:54
Modified files:
hw : sun4m.c
Log message:
Fix TCX base on SS10
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.32&r2=1.33
_
On Saturday 07 April 2007 19:32, J. Mayer wrote:
> On Sat, 2007-04-07 at 18:14 +, Paul Brook wrote:
> > CVSROOT: /sources/qemu
> > Module name: qemu
> > Changes by: Paul Brook07/04/07 18:14:41
>
> The patches in the PowerPC target seem complete nonsense.
Can you give specific
On Saturday 07 April 2007 19:32, J. Mayer wrote:
> On Sat, 2007-04-07 at 18:14 +, Paul Brook wrote:
> > CVSROOT:/sources/qemu
> > Module name:qemu
> > Changes by: Paul Brook 07/04/07 18:14:41
>
> The patches in the PowerPC target seem complete nonsense.
Can you give specific e
On Sat, 2007-04-07 at 18:14 +, Paul Brook wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Paul Brook 07/04/07 18:14:41
The patches in the PowerPC target seem complete nonsense.
Furthermore, this kind of patch that break other guys work would likely
to be discusse
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/04/07 18:14:41
Modified files:
. : Makefile.target vl.h
hw : acpi.c adlib.c apb_pci.c arm_gic.c arm_pic.c
arm_pic.h arm_timer.c cs4231.c cuda.c
> I don't think that tunneling traffic through VNC is possible. In QEMU the
> VNC implementation is asynchronous, while the USB layer expects an
> immediate response to any request.
Not entirely true. While some transfers (typically control transfers) are
synchronous, bulk transfers can by asynch
Hi Anthony,
I don't know all that much about USB, but I think the most useful way to
do this would be to do something that's protocol compatible with USBIP.
Neither I do. I didn't know anything about USB/IP, it would be cool to be
protocol compatible with it. As we have to start from scratch,
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/04/07 11:48:04
Modified files:
target-ppc : op.c
Log message:
PowerPC 64 fixes
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.31&r2=1.32
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/04/07 11:21:28
Modified files:
. : cpu-all.h exec.c
target-alpha : helper.c
target-arm : helper.c
target-i386: helper2.c
target-m68k: translat
22 matches
Mail list logo
