Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Blue Swirl

On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote:

DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro.
Now, it's evolving more into a-la-slax type of distro.


As the number of Sparc32 distributions keeps approaching zero, could
you consider porting DetaolB to non-x86 CPUs?




Re: [Qemu-devel] sparc guest

2007-06-30 Thread Andreas Färber
With the lance network fixed being able to do some more now, I am  
seeing a number of other issues:


- When there is a network timeout the console starts  
scrolling (text moves up and screen stays blank).
To reproduce, run svn checkout svn://10.0.0.1 (with 10.0.0.1 not  
available). On others systems the screen stays as is and only  
displays a timeout error message in the end.


- Already during initial Debian installation attempt I kept getting  
kernel panics (previous thread).
Now I am getting more of those and they appear to be connected to  
esp0 problems. Once I got an infinite loop of esp0 timeout messages  
during boot (not reproducable). But reproducably I get some esp0  
output and then kernel panic while running Mono 1.2.4's ./configure  
script (see screenshot).


Do you have any idea where those problems might originate? Any  
thoughts how to fix or work around them? ./configure -C does not work  
unfortunately.


Andreas
inline: Q Screenshot 1.png

Re: [Qemu-devel] sparc guest

2007-06-30 Thread Andreas Färber


Once I got an infinite loop of esp0 timeout messages during boot  
(not reproducable).


Just got it again, it's:
esp0: Data transfer overrun.







Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Johannes Schindelin
Hi,

On Sat, 30 Jun 2007, Blue Swirl wrote:

 On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote:
  DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. 
  Now, it's evolving more into a-la-slax type of distro.
 
 As the number of Sparc32 distributions keeps approaching zero, could you 
 consider porting DetaolB to non-x86 CPUs?

Yes, please!

Ciao,
Dscho





Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Thiemo Seufer
Johannes Schindelin wrote:
 Hi,
 
 On Sat, 30 Jun 2007, Blue Swirl wrote:
 
  On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote:
   DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. 
   Now, it's evolving more into a-la-slax type of distro.
  
  As the number of Sparc32 distributions keeps approaching zero, could you 
  consider porting DetaolB to non-x86 CPUs?
 
 Yes, please!

The reason why distributions drop sparc32 is the unmaintained kernel.
Nobody stepped up for Linux kernel maintenance in the last years.
Debian managed to keep up a sort-of working kernel for the last
release, the people who put their time into it are disinclined to
repeat this exercise.


Thiemo




Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Christian MICHON

On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote:

The reason why distributions drop sparc32 is the unmaintained kernel.
Nobody stepped up for Linux kernel maintenance in the last years.
Debian managed to keep up a sort-of working kernel for the last
release, the people who put their time into it are disinclined to
repeat this exercise.



good point. I'm not a kernel maintainer, I'm just a distro maker.

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu




Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Christian MICHON

On 6/30/07, Johannes Schindelin [EMAIL PROTECTED] wrote:

Hi,

On Sat, 30 Jun 2007, Blue Swirl wrote:

 On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote:
  DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro.
  Now, it's evolving more into a-la-slax type of distro.

 As the number of Sparc32 distributions keeps approaching zero, could you
 consider porting DetaolB to non-x86 CPUs?

Yes, please!

Ciao,
Dscho



there might be a arm port (I'll need to figure out the framebuffer part though).

the original target of detaolb is to have a quick x86 development environment
that can boot/run quickly in qemu.

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu




[Qemu-devel] qemu exec.c monitor.c

2007-06-30 Thread Paul Brook
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/06/30 13:53:24

Modified files:
.  : exec.c monitor.c 

Log message:
Allow changing log filename.
Close logfile when logging is disabled.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.101r2=1.102
http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemur1=1.74r2=1.75




[Qemu-devel] Patches

2007-06-30 Thread Ben Taylor

There are two patches included in the mail

1) qemu-sdl-error.diff - patch to capture output from the sdl compile test, and 
output it if there
 is an error at reporting time (and delete the file when finished)

2) qemu-sdl-whitespace.diff -  patch to fix the indentation for the sdl-config 
section

Ben--- qemu/configure	2007-06-23 12:03:35.0 -0400
+++ ../062707/qemu/configure	2007-06-28 17:55:52.348903000 -0400
@@ -553,7 +553,7 @@
 int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
 EOF
 
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /dev/null ; then
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
 _sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
 if test $_sdlversion -lt 121 ; then
 sdl_too_old=yes
@@ -562,6 +562,9 @@
sdl=yes
  fi
 fi
+if [ -s /tmp/qemu-sdl-config.log ]; then
+  check_sdl_log=yes
+fi
 
 # static link with sdl ?
 if test $sdl = yes ; then
@@ -688,6 +691,11 @@
 if test $sdl_too_old = yes; then
 echo - Your SDL version is too old - please upgrade to have SDL support
 fi
+if test $check_sdl_log = yes; then
+  echo The error log from compiling the libSDL test is: 
+  cat /tmp/qemu-sdl-config.log
+fi
+/usr/bin/rm -f /tmp/qemu-sdl-config.log
 #if test $sdl_static = no; then
 #  echo WARNING: cannot compile statically with SDL - qemu-fast won't have a graphical output
 #fi
--- configure.ORIG	2007-06-29 22:59:52.754312000 -0400
+++ configure	2007-06-29 23:11:11.638889000 -0400
@@ -537,60 +537,60 @@
 
 if test -z $sdl ; then
 
-sdl_config=sdl-config
-sdl=no
-sdl_static=no
-
-if test $mingw32 = yes -a ! -z $cross_prefix ; then
-# win32 cross compilation case
-sdl_config=i386-mingw32msvc-sdl-config
-sdl=yes
-else
-# normal SDL probe
+sdl_config=sdl-config
+sdl=no
+sdl_static=no
+
+if test $mingw32 = yes -a ! -z $cross_prefix ; then
+# win32 cross compilation case
+sdl_config=i386-mingw32msvc-sdl-config
+sdl=yes
+else
+# normal SDL probe
 cat  $TMPC  EOF
 #include SDL.h
 #undef main /* We don't want SDL to override our main() */
 int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
 EOF
 
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
-_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
-if test $_sdlversion -lt 121 ; then
-sdl_too_old=yes
-else
- if test $cocoa = no ; then
-   sdl=yes
- fi
-fi
-if [ -s /tmp/qemu-sdl-config.log ]; then
-  check_sdl_log=yes
-fi
-
-# static link with sdl ?
-if test $sdl = yes ; then
-aa=no
-`$sdl_config --static-libs 2/dev/null | grep \\\-laa  /dev/null`  aa=yes
-sdl_static_libs=`$sdl_config --static-libs 2/dev/null`
-if [ $aa = yes ] ; then
-  sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
-fi
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
+_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
+if test $_sdlversion -lt 121 ; then
+sdl_too_old=yes
+else
+if test $cocoa = no ; then
+sdl=yes
+fi
+fi
+if [ -s /tmp/qemu-sdl-config.log ]; then
+check_sdl_log=yes
+fi
+
+# static link with sdl ?
+if test $sdl = yes ; then
+aa=no
+`$sdl_config --static-libs 2/dev/null | grep \\\-laa  /dev/null`  aa=yes
+sdl_static_libs=`$sdl_config --static-libs 2/dev/null`
+if [ $aa = yes ] ; then
+sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
+fi
+
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+sdl_static=yes
+fi
 
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
-  sdl_static=yes
-fi
+fi # static link
 
-fi # static link
+fi # sdl compile test
 
-fi # sdl compile test
-
-fi # cross compilation
+fi # cross compilation
 
 else
- # Make sure to disable cocoa if sdl was set
- if test $sdl = yes ; then
-   cocoa=no
-   coreaudio=no
- fi
+# Make sure to disable cocoa if sdl was set
+if test $sdl = yes ; then
+cocoa=no
+coreaudio=no
+fi
 fi # -z $sdl
 
 ##


Re: [Qemu-devel] ANN: DetaolB v0.4 is released

2007-06-30 Thread Blue Swirl

On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote:

Johannes Schindelin wrote:
 Hi,

 On Sat, 30 Jun 2007, Blue Swirl wrote:

  On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote:
   DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro.
   Now, it's evolving more into a-la-slax type of distro.
 
  As the number of Sparc32 distributions keeps approaching zero, could you
  consider porting DetaolB to non-x86 CPUs?

 Yes, please!

The reason why distributions drop sparc32 is the unmaintained kernel.
Nobody stepped up for Linux kernel maintenance in the last years.
Debian managed to keep up a sort-of working kernel for the last
release, the people who put their time into it are disinclined to
repeat this exercise.


But there is a difference in maintaining a kernel suitable for high
quality distribution with over 18733 packages working in different
real hardware, versus a test/evaluation distribution with 30 packages
running on Qemu. I'd see that as an enhanced qemu-tests.tar.gz.




[Qemu-devel] qemu Makefile.target vl.h hw/integratorcp.c hw/...

2007-06-30 Thread Paul Brook
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/06/30 17:32:17

Modified files:
.  : Makefile.target vl.h 
hw : integratorcp.c realview.c versatilepb.c 
Added files:
hw : pl031.c 

Log message:
ARM PL031 RTC emulation.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.185r2=1.186
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.254r2=1.255
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.18r2=1.19
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.9r2=1.10
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.15r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl031.c?cvsroot=qemurev=1.1




Re: [Qemu-devel] VersatetilePB: request for comments on PL031 patch

2007-06-30 Thread Paul Brook
On Friday 15 June 2007, Simone wrote:
 Hello,

 My name is Simone Basso, and I study Computer Science at Politecnico di
 Torino, Italy. In the three past weeks I've been working to a project that
 involves Qemu, as a part of an exam, together with another student, Gaspare
 Scherma.

You implementation seems seriously over-complicated (AFAICS all struct tm bits 
are completely unnecessary) and missing a few other bits, so I rewrote it.

Paul




Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port

2007-06-30 Thread Gilad Ben-Yossef

Anthony Liguori wrote:


The machine running qemu has a web based interface to start VMs.
A user asks for a new VM to start by browsing to a URL. The CGI
implmenting that URL will start a new qemu instance, send to the user
web browser an HTML page with a JAVA VNC viewer embedded and terminate.


Passing an fd is still the wrong solution due to the problems with 
save/restore/migrate.


There is no problem with save/restore or migration.

For save/restore, the fd is not saved in the saved state. You need to 
specify a (new?) fd when you restore, if that is what you want to do, 
that is.


It just like I can run a VM with SDL, save the state and restore it with 
VNC - the question if the restored session should use the same fd (for 
whatever definition of the same you want) or not is left for the user. 
We should be providing mechanism, not policy.


The same applies for migration - when you migrate your VM, its your call 
and responsibility to do the right thing. Just spawn a wrapper on the 
target machine that opens a new fd and exec into qemu and use *that* as 
your migrate command line argument instead of plain qemu, as an obvious 
example.


As someone wrote in their blog (this is why I write my blog in a 
language that's been dead for aprox. 2000 years... :-):


Instead of just saying 'migrate hostname' you now have to construct a 
rather long command like 'migrate ssh hostname qemu -loadvm -'. A nice 
side effect though is that you can completely change the command line 
arguments in case you have NFS mounts at different locations.


I couldn't agree more. :-)




It may be interesting to have something like -vnc 
tcp://0.0.0.0:5900-6000 to let QEMU try to find an unused port in the 
given range.  Combined with -daemonize and having the monitor on a Unix 
socket, you could:


1) create a vm with qemu -vnc tcp://0.0.0.0:5900-6000 -monitor 
unix:/path/to/socket -daemonize

2) *wait* for qemu to finish running and daemonize properly
3) connect to /path/to/socket and issue a 'info vnc' command to discover 
which port it's actually using

4) render that port with your HTML.


What you're saying is the same as claiming that ls needs to implement 
sorting, compression (in both gz and bzip algorithms), regexp searching 
and transferring it's output over an SSL connection to another machine.


We don't do that. We have pipes . VNC socket fd passing is just the old 
pipe concept (adapted to the situation) - nothing more.


Or in other words: you can easily implement the VNC over unix domain 
socket feature (if it was not in qemu already) using the fd passing 
method, but you can't do it the other way around (without an extra long 
running process, that is)




The nice thing about this is that it not only continues to work with 
save/restore/migrate, it's smart enough to allocate a new port to ensure 
that you always tend to succeed.  Choosing :3 might be okay on machine 
A, but there's no guarantee that it's okay on machine B so you have to 
allow QEMU to try and find a new port after restore/migrate.


You're assuming we know what the correct behavior is. We really don't 
know. Maybe we want to use the same fd number on the new machine, maybe 
we don't. The user somehow provided a good fd on the original machine, 
trust him to provide a good one on the new one (via a qemu wrapper for 
migrate as explained above, for example).


Again it's that mechanism vs. policy thing again.,

Gilad

PS. This is not some ego trip about whether you'll take the patch or 
not, so just tell me if this back and forth gets annoying and I'll shut 
up :-)