Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Am 28.07.2007 um 12:36 schrieb Thiemo Seufer: qemu seems to expect everyone to patch it herself instead of fixing problems in the repository at their origin. Major example being qemu clinging on to GCC 3.x instead of supporting both 3 and 4 by updating and integrating the existing patches th

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Thiemo Seufer wrote: The problem is the linker (presumably /usr/bin/ld) does not find the math library (likely name is /lib/libm.so.6). You can add "-v" to the gcc command line to find out what it looks for. JFTR, building qemu on Debian mips worked for me some days ago, but the resulting binary

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Andreas Färber wrote: > > Am 27.07.2007 um 16:58 schrieb Sunil Amitkumar Janki: > >> Dan Shearer wrote: >>> I see this as a different class of testing >>> [...], checking out and compiling >>> under different circumstances. That's very valuable, and will help >>> address a problem that drives away

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Sunil Amitkumar Janki wrote: > Thiemo Seufer wrote: >> A missing libm sounds like a build environment problem. >> >> Thiemo > > Do you have a test for this because I reinstalled the entire > system from scratch and have had no problems building > lots of packages over the last week except for those

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

- Original Message From: Paul Brook <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org Cc: n schembr <[EMAIL PROTECTED]> Sent: Friday, July 27, 2007 1:38:19 PM Subject: Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...) > >

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

> >> how close is thread safey? > > > > In a useful form: a fair way off. > > > > It's relatively simple to hack something together than runs. Making it > > work correctly and go fast is much harder though. My current prototype > > (running on 2 cores) runs about a quarter the speed of normal qemu,

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Thiemo Seufer wrote: A missing libm sounds like a build environment problem. Thiemo Do you have a test for this because I reinstalled the entire system from scratch and have had no problems building lots of packages over the last week except for those applications that assume that all the worl

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Sunil Amitkumar Janki wrote: [snip] >> gcc -g -Wl,-T,/root/tmp/qemu-20070727/mipsel.ld -o qemu-i386 main.o >> syscall.o mmap.o signal.o path.o osdep.o thunk.o elfload.o linuxload.o >> vm86.o libqemu.a gdbstub.o -lm -lrt -lasound >> /usr/bin/ld: cannot find -lm >> collect2: ld returned 1 exit

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Am 27.07.2007 um 16:58 schrieb Sunil Amitkumar Janki: Dan Shearer wrote: I see this as a different class of testing [...], checking out and compiling under different circumstances. That's very valuable, and will help address a problem that drives away a lot of potential QEMU users - they ju

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Paul Brook wrote: As Qemu cannot use multicore CPUs (partially due to missing thread safety), yet, you won't benefit from this unless you want to run multiple instances of Qemu in parallel. how close is thread safey? In a useful form: a fair way off. It's relatively simple to hack

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

> >As Qemu cannot use multicore CPUs (partially due to missing thread > >safety), yet, you won't benefit from this unless you want to run > >multiple instances of Qemu in parallel. > > how close is thread safey? In a useful form: a fair way off. It's relatively simple to hack something together t

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

- Original Message From: Jan Marten Simons <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org Sent: Friday, July 27, 2007 12:50:51 PM Subject: Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...) Sunil Amitkumar Janki schrieb: > Dan Shea

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Sunil Amitkumar Janki schrieb: Dan Shearer wrote: You do also have the architectures provided to you by QEMU :-) :-) I have been able to build modular Xorg for Armedslack in QEMU without having the hardware but when I tried to port Slackware 12.0 to SPARC in QEMU I found it was way too slow

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On Fri, Jul 27, 2007 at 05:50:05PM +0200, Sunil Amitkumar Janki wrote: > Dan Shearer wrote: > >You do also have the architectures provided to you by QEMU :-) :-) > > Maybe in the future where we have all kinds of cheap multicore processors > this will not matter much but for the moment limited res

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Dan Shearer wrote: You do also have the architectures provided to you by QEMU :-) :-) I have been able to build modular Xorg for Armedslack in QEMU without having the hardware but when I tried to port Slackware 12.0 to SPARC in QEMU I found it was way too slow and started looking for some re

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On Fri, Jul 27, 2007 at 04:58:19PM +0200, Sunil Amitkumar Janki wrote: > Dan Shearer wrote: > > > >I see this as a different class of testing to the tinderbox-style > >testing Natalia Portillo was talking about, checking out and compiling > >under different circumstances. That's very valuable, and

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Dan Shearer wrote: On Fri, Jul 27, 2007 at 09:29:11AM -0500, Anthony Liguori wrote: FYI, I've started building a VNC based automated tester. You provide it a series of screenshots with masks of data that's likely to be That's excellent. I see this as a different class of testing to

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On Fri, Jul 27, 2007 at 09:29:11AM -0500, Anthony Liguori wrote: > FYI, I've started building a VNC based automated tester. You provide it > a series of screenshots with masks of data that's likely to be That's excellent. I see this as a different class of testing to the tinderbox-style testin

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

FYI, I've started building a VNC based automated tester. You provide it a series of screenshots with masks of data that's likely to be semi-random and it'll wait for each screen shot. It also has the smarts to find where the mouse is so that you can move it to an exact location. I'll have so

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On Sun, Apr 08, 2007 at 09:43:20PM +0100, Natalia Portillo wrote: Whoops, slightly late reply :-) > I have a huge list of operating systems (both closed and open source, that > works and that doesn't work under QEMU) that can be used to check that QEMU > doesn't broke (or even, that it corrects a

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On 8 avr. 07, at 22:43, Natalia Portillo wrote: But that required some macro interface "click at x,y, wait some seconds, press 'k' key", that is not currently under QEMU. There is cxtest (GPL) which has been created for that matter, it should be interesting to give it a try: http://www.c

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Natalia Portillo wrote: > But that required some macro interface "click at x,y, wait some seconds, > press 'k' key", that is not currently under QEMU. > > The best solution I think is to get a way to send QEMU the screenshot to > file command some times and stop the VM when both are equal, then se

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

On Sunday 08 April 2007 4:43 pm, Natalia Portillo wrote: > Hi all, > > I have a huge list of operating systems (both closed and open source, that > works and that doesn't work under QEMU) that can be used to check that QEMU > doesn't broke (or even, that it corrects a non-working state). I vaguel

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Sorry, I'm afraid I badly mixed up things in my mind. vncrec and pyvnc2swf record VNC server responses, not client actions, so they will hardly be of any help. To record and replay client actions these tools are more appropriate: http://cyberelk.net/tim/rfbproxy/ http://cyberelk.net/tim/rfbplay

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

It doesn't fullfil the requirements for an automated testing, however, it is a good idea, but not inside the plannings I proposed. El 08/04/2007, a las 23:07, Eduardo Felipe escribió: But that required some macro interface "click at x,y, wait some seconds, press 'k' key", that is not curr

Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

But that required some macro interface "click at x,y, wait some seconds, press 'k' key", that is not currently under QEMU. It does exist... it's called VNC server. Maybe you can have a look at: http://www.sodan.org/~penny/vncrec/ or http://suif.stanf

QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

Hi all, I have a huge list of operating systems (both closed and open source, that works and that doesn't work under QEMU) that can be used to check that QEMU doesn't broke (or even, that it corrects a non-working state). I've already discussed that with Fabrice. And I think it is better to chec