CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_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:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_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=qemur1=1.31r2=1.32
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
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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 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
On Sat, 2007-04-07 at 18:14 +, 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.
Furthermore, this kind of patch that break other guys work would likely
to be
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 pbrook 07/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 pbrook 07/04/07 18:14:41
The patches in the PowerPC target seem complete nonsense.
Can you give specific
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir107/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=qemur1=1.32r2=1.33
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
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 pbrook 07/04/07 18:14:41
The patches in the
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 by: Paul
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
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 pbrook 07/04/07 18:14:41
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
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 most real
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]
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
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
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
20 matches
Mail list logo
