On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should compile on
every platform for
On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/09/16 21:08:06
Modified files:
. : Changelog Makefile Makefile.target TODO aes.c
alpha-dis.c arm-dis.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/17 08:09:55
Modified files:
. : Changelog aes.c arm-dis.c arm-semi.c
block-bochs.c block-cloop.c block-cow.c
block-dmg.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_mayer 07/09/17 08:21:54
Modified files:
hw : ppc405_uc.c ppc_chrp.c ppc_prep.c
target-ppc : cpu.h exec.h helper.c op.c op_helper.c
op_helper_mem.h op_mem.h
On 9/17/07, Thiemo Seufer [EMAIL PROTECTED] wrote:
Log message:
find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the
star in the regex.
so you're going to do this each time you receive a faulty patch ?
I thought this kind of search and replace is more likely to happen
On 9/17/07, J. Mayer [EMAIL PROTECTED] wrote:
Log message:
find -type f | xargs sed -i 's/[\t ]$//g' # on most files
Many thanks for generating hundreds of conflicts with a useless commit.
Don't know what's wrong in your expression but it did not what you think
it should (and you did
Andreas Schwab wrote:
Your reference to ULONG_MAX is a red herring. ULONG_MAX is the limit
for unsigned long, and ULONG_LONG_MAX is the limit for unsigned long
long. If your compiler does not support the long long type then
ULONG_LONG_MAX should not be defined either. Instead, vl.c should
Hi,
On Mon, 17 Sep 2007, J. Mayer wrote:
On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/16 21:08:06
[lots of changes]
Log message:
find -type f | xargs sed -i 's/[\t ]$//g' #
On Mon, 2007-09-17 at 10:27 +0200, Christian MICHON wrote:
On 9/17/07, J. Mayer [EMAIL PROTECTED] wrote:
Log message:
find -type f | xargs sed -i 's/[\t ]$//g' # on most files
Many thanks for generating hundreds of conflicts with a useless commit.
Don't know what's wrong in your
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_mayer 07/09/17 09:51:40
Modified files:
target-ppc : op.c op_helper.c op_mem.h translate.c
Log message:
PowerPC flags update/use fixes:
- fix confusion between overflow/summary
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
if we were using git (but you can do it locally anyway), you would not
have these conflicts problems...
Maybe... but Savannah uses a CVS frontend, as far as I know...
Those are excuses.
So is a you should have used X argument. It doesn't
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote:
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
if we were using git (but you can do it locally anyway), you would not
have these conflicts problems...
Maybe... but Savannah uses a CVS frontend, as far as I know...
Those are
J. Mayer wrote:
On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/16 21:08:06
Modified files:
. : Changelog Makefile Makefile.target TODO aes.c
Christian MICHON wrote:
On 9/17/07, Thiemo Seufer [EMAIL PROTECTED] wrote:
Log message:
find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the
star in the regex.
so you're going to do this each time you receive a faulty patch ?
I did so for some months now.
I
On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation
In message: [EMAIL PROTECTED]
Johannes Schindelin [EMAIL PROTECTED] writes:
: Hi,
:
: On Mon, 17 Sep 2007, J. Mayer wrote:
:
: On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote:
: CVSROOT: /sources/qemu
: Module name: qemu
: Changes by: Thiemo Seufer ths
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/09/17 17:27:00
Modified files:
hw : usb-hid.c
Log message:
Pass correct pointer to HID keyboard event handler, fixes regression
from IDLE mode introduction.
CVSWeb
[sorry, resending.. didn't make it to xen-devel]
On Thu, 2007-13-09 at 12:41 +, Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/09/13 12:41:43
Modified files:
. : vnc.c
Log message:
Fix infinite
Am 17.09.2007 um 14:18 schrieb Christian MICHON:
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote:
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
if we were using git (but you can do it locally anyway), you
would not
have these conflicts problems...
Maybe... but Savannah uses a CVS
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote:
Am 17.09.2007 um 14:18 schrieb Christian MICHON:
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote:
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
if we were using git (but you can do it locally anyway), you
would not
have these
It seems to me that there are many problems in linux-user/syscall.c
- minor fixes, just to avoid compilation warnings:
do_socketcall should be inside a #ifdef TARGET_NR_socketcall block
do_ipc should be inside a #ifdef TARGET_NR_ipc block
- problems for 64 bits targets:
it seems that do_syscall
On Mon, 2007-09-17 at 23:14 +0200, Luca wrote:
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote:
Am 17.09.2007 um 14:18 schrieb Christian MICHON:
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote:
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
if we were using git (but you can do
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote:
Evolve, or prepare to be assimilated into the Collective...
Both the qemu.org and the Savannah project page only mention CVS. If
there are better ways to get the code then inform your users how to
use that. Writing only of CVS and then
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/09/17 21:25:21
Modified files:
. : vl.c
Log message:
Prevent segfaulting when -clock is specified multiple times.
CVSWeb URLs:
On Monday 17 September 2007, J. Mayer wrote:
It seems to me that there are many problems in linux-user/syscall.c
- problems for 64 bits targets:
it seems that do_syscall and child functions should take target_long /
target_ulong arguments instead of long / unsigned long. This would make
a
On Mon, 2007-09-17 at 23:10 +0100, Paul Brook wrote:
On Monday 17 September 2007, J. Mayer wrote:
It seems to me that there are many problems in linux-user/syscall.c
- problems for 64 bits targets:
it seems that do_syscall and child functions should take target_long /
target_ulong
Hi,
On Mon, 17 Sep 2007, Andreas F?rber wrote:
Both the qemu.org and the Savannah project page only mention CVS. If
there are better ways to get the code then inform your users how to use
that.
What about graphical diff tools? Should you _not_ use them, because CVS
has an in-built diff?
J. Mayer [EMAIL PROTECTED] wrote:
On Mon, 2007-09-17 at 23:14 +0200, Luca wrote:
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote:
Am 17.09.2007 um 14:18 schrieb Christian MICHON:
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote:
DON'T DO THIS KIND OF COMMIT AGAIN,
Jocelyn Mayer wrote:
On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried
Alexander Graf wrote:
Jocelyn Mayer wrote:
I don't see any practical reason not to do it this way. We could define
a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
target specific CPUState, but this would hit performance (marginally
though) and does not improve the
Hi guys,
I'm studying Virtual Machines, and I would like to read something
about QEMU... Does anybody know a paper(s) that shows how I/O works
in qemu (I have interest in how qemu emulate network interface).
Thanks in advance...
Att.
Artur Baruchi
Hi,
I am a newcomer to QEMU. I am trying to understand the QEMU code. I am a little
bit confused about the following code about chaining TBs with direct jump
(cpu-exec.c, line 611, I edited it to remove #ifdef to make it clear to
discussion):
if (T0 != 0 tb-page_addr[1] == -1
Artur Baruchi schreef:
Hi guys,
I'm studying Virtual Machines, and I would like to read something
about QEMU... Does anybody know a paper(s) that shows how I/O works
in qemu (I have interest in how qemu emulate network interface).
Thanks in advance...
Att.
Artur Baruchi
Don't exactly
34 matches
Mail list logo
