[Qemu-devel] [5524] Fix windows build after migration changes

[Qemu-devel] [5524] Fix windows build after migration changes

[Anthony Liguori]

Revision: 5524
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5524
Author:   aliguori
Date:     2008-10-24 14:11:41 +0000 (Fri, 24 Oct 2008)

Log Message:
-----------
Fix windows build after migration changes

The live migration code broke the windows build.  As part of this 
change, I've switched the BIOS path to C:\Program Files\Qemu instead of 
/c/Program Files/Qemu.  The later is only valid when launching from MSYS 
but the former is always valid.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Modified Paths:
--------------
    trunk/configure
    trunk/migration-tcp.c
    trunk/vl.c

Modified: trunk/configure
===================================================================
--- trunk/configure	2008-10-24 13:12:52 UTC (rev 5523)
+++ trunk/configure	2008-10-24 14:11:41 UTC (rev 5524)
@@ -953,7 +953,7 @@
 
 if test "$mingw32" = "yes" ; then
   if test -z "$prefix" ; then
-      prefix="/c/Program Files/Qemu"
+      prefix="c:\\\\Program Files\\\\Qemu"
   fi
   mansuffix=""
   datasuffix=""

Modified: trunk/migration-tcp.c
===================================================================
--- trunk/migration-tcp.c	2008-10-24 13:12:52 UTC (rev 5523)
+++ trunk/migration-tcp.c	2008-10-24 14:11:41 UTC (rev 5524)
@@ -84,7 +84,7 @@
     ssize_t ret;
 
     do {
-        ret = write(s->fd, data, size);
+        ret = send(s->fd, data, size, 0);
     } while (ret == -1 && errno == EINTR);
 
     if (ret == -1)
@@ -262,7 +262,7 @@
 	return NULL;
     }
 
-    fcntl(s->fd, F_SETFL, O_NONBLOCK);
+    socket_set_nonblock(s->fd);
 
     if (s->detach == 1) {
         dprintf("detaching from monitor\n");

Modified: trunk/vl.c
===================================================================
--- trunk/vl.c	2008-10-24 13:12:52 UTC (rev 5523)
+++ trunk/vl.c	2008-10-24 14:11:41 UTC (rev 5524)
@@ -6224,9 +6224,8 @@
         len = announce_self_create(buf, nd_table[i].macaddr);
         vlan = nd_table[i].vlan;
         for(vc = vlan->first_client; vc != NULL; vc = vc->next) {
-            if (vc->fd_read == tap_receive)  /* send only if tap */
-                for (j=0; j < SELF_ANNOUNCE_ROUNDS; j++)
-                    vc->fd_read(vc->opaque, buf, len);
+            for (j=0; j < SELF_ANNOUNCE_ROUNDS; j++)
+                vc->fd_read(vc->opaque, buf, len);
         }
     }
 }

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Robert Riebisch]

Anthony Liguori wrote:

> The live migration code broke the windows build.  As part of this 
> change, I've switched the BIOS path to C:\Program Files\Qemu instead of 
> /c/Program Files/Qemu.  The later is only valid when launching from MSYS 
> but the former is always valid.

Why do you always want the BIOS path hard-coded? I've made a small patch
for QEMU 0.9.1 to determine path, i.e. current directory, at runtime. I
could send it to you for adapting to SVN.

Robert Riebisch
-- 
BTTR Software
http://www.bttr-software.de/

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Glauber Costa]

On Fri, Oct 24, 2008 at 12:18 PM, Robert Riebisch <rr@bttr-software.de> wrote:
> Anthony Liguori wrote:
>
>> The live migration code broke the windows build.  As part of this
>> change, I've switched the BIOS path to C:\Program Files\Qemu instead of
>> /c/Program Files/Qemu.  The later is only valid when launching from MSYS
>> but the former is always valid.
>
> Why do you always want the BIOS path hard-coded? I've made a small patch
> for QEMU 0.9.1 to determine path, i.e. current directory, at runtime. I
> could send it to you for adapting to SVN.

This is a bad idea, IMHO. We currently do have an option to allow for
runtime selecting
bios image locations, with the -L switch. The hardcoded version is a
fallback, and for that case,
it's better to be totally explicit about which directory we're picking
things from.



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Robert Riebisch]

Glauber Costa wrote:

> This is a bad idea, IMHO. We currently do have an option to allow for
> runtime selecting
> bios image locations, with the -L switch. The hardcoded version is a
> fallback, and for that case,
> it's better to be totally explicit about which directory we're picking
> things from.

This might be OK for other OS's. But on Windows people don't expect such
behaviour. People new to QEMU get often confused by using "-L ." or
something similar.
And what if I installed Windows not on drive C:? (Yes, that's possible.)
Or if I have a non-English version? For example, "Program Files" is
called "Programme" in German versions of Windows.

Robert Riebisch
P.S. Could you please repair your line length limit?
-- 
BTTR Software
http://www.bttr-software.de/

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Glauber Costa]

On Fri, Oct 24, 2008 at 12:55 PM, Robert Riebisch <rr@bttr-software.de> wrote:
> Glauber Costa wrote:
>
>> This is a bad idea, IMHO. We currently do have an option to allow for
>> runtime selecting
>> bios image locations, with the -L switch. The hardcoded version is a
>> fallback, and for that case,
>> it's better to be totally explicit about which directory we're picking
>> things from.
>
> This might be OK for other OS's. But on Windows people don't expect such
> behaviour. People new to QEMU get often confused by using "-L ." or
> something similar.
> And what if I installed Windows not on drive C:? (Yes, that's possible.)
> Or if I have a non-English version? For example, "Program Files" is
> called "Programme" in German versions of Windows.
Yes, I figured that out after anthony's reply.  Anyway, I believe
current working directory is not a good choice, as it is too easy
to misuse.


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Robert Riebisch]

Glauber Costa wrote:

> Anyway, I believe
> current working directory is not a good choice, as it is too easy
> to misuse.

Sorry, I'm not getting the point. Could you please tell me how?

Robert Riebisch
-- 
BTTR Software
http://www.bttr-software.de/

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Glauber Costa]

On Fri, Oct 24, 2008 at 1:08 PM, Robert Riebisch <rr@bttr-software.de> wrote:
> Glauber Costa wrote:
>
>> Anyway, I believe
>> current working directory is not a good choice, as it is too easy
>> to misuse.
>
> Sorry, I'm not getting the point. Could you please tell me how?
Yes, easily.

CWD is not fixed by definition. It's very easy to just have files in there
that ressembles bios images, and so they get used by accident. Xen
had some things like that for restoring saved images, and it happened
to me a lot of times. Things then just start to not work reliably, and
it takes some time for you to figure it out why. All because the
decision is implicit, rather than explicit.

>
> Robert Riebisch
> --
> BTTR Software
> http://www.bttr-software.de/
>
>
>



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Anthony Liguori]

Robert Riebisch wrote:
> Anthony Liguori wrote:
>
>   
>> The live migration code broke the windows build.  As part of this 
>> change, I've switched the BIOS path to C:\Program Files\Qemu instead of 
>> /c/Program Files/Qemu.  The later is only valid when launching from MSYS 
>> but the former is always valid.
>>     
>
> Why do you always want the BIOS path hard-coded? I've made a small patch
> for QEMU 0.9.1 to determine path, i.e. current directory, at runtime. I
> could send it to you for adapting to SVN.
>   

That would be great.  I don't know that we want to go on the current 
directory though.  There's a Windows API for finding Program Files.  
That's probably what we want to do.

Regards,

Anthony Liguori

> Robert Riebisch
>   

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Robert Riebisch]

Anthony Liguori wrote:

> That would be great.  I don't know that we want to go on the current 
> directory though.  There's a Windows API for finding Program Files.  
> That's probably what we want to do.

Why do you want to look for "Program Files" instead? Just let QEMU
determine its own folder via GetModuleFileName() and look there for the
BIOS files.

One of the main advantages of QEMU over other virtualization products is
that you can copy it to whatever folder you like. Even to a USB flash
drive/memory key for complete portability.

Robert Riebisch
-- 
BTTR Software
http://www.bttr-software.de/

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Anthony Liguori]

Robert Riebisch wrote:
> Anthony Liguori wrote:
>
>   
>> That would be great.  I don't know that we want to go on the current 
>> directory though.  There's a Windows API for finding Program Files.  
>> That's probably what we want to do.
>>     
>
> Why do you want to look for "Program Files" instead? Just let QEMU
> determine its own folder via GetModuleFileName() and look there for the
> BIOS files.
>   

That's not the same as CWD and is probably the right thing to do.

Regards,

Anthony Liguori

> One of the main advantages of QEMU over other virtualization products is
> that you can copy it to whatever folder you like. Even to a USB flash
> drive/memory key for complete portability.
>
> Robert Riebisch
>   

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Glauber Costa]

On Fri, Oct 24, 2008 at 1:11 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Robert Riebisch wrote:
>>
>> Anthony Liguori wrote:
>>
>>
>>>
>>> That would be great.  I don't know that we want to go on the current
>>> directory though.  There's a Windows API for finding Program Files.  That's
>>> probably what we want to do.
>>>
>>
>> Why do you want to look for "Program Files" instead? Just let QEMU
>> determine its own folder via GetModuleFileName() and look there for the
>> BIOS files.
>>
>
> That's not the same as CWD and is probably the right thing to do.

Agreed.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Paul Brook]

On Friday 24 October 2008, Anthony Liguori wrote:
> Robert Riebisch wrote:
> > Anthony Liguori wrote:
> >> That would be great.  I don't know that we want to go on the current
> >> directory though.  There's a Windows API for finding Program Files.
> >> That's probably what we want to do.
> >
> > Why do you want to look for "Program Files" instead? Just let QEMU
> > determine its own folder via GetModuleFileName() and look there for the
> > BIOS files.
>
> That's not the same as CWD and is probably the right thing to do.

We could also do the same thing for Linux et al.

Paul

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Anthony Liguori]

Paul Brook wrote:
> On Friday 24 October 2008, Anthony Liguori wrote:
>   
>> Robert Riebisch wrote:
>>     
>>> Anthony Liguori wrote:
>>>       
>>>> That would be great.  I don't know that we want to go on the current
>>>> directory though.  There's a Windows API for finding Program Files.
>>>> That's probably what we want to do.
>>>>         
>>> Why do you want to look for "Program Files" instead? Just let QEMU
>>> determine its own folder via GetModuleFileName() and look there for the
>>> BIOS files.
>>>       
>> That's not the same as CWD and is probably the right thing to do.
>>     
>
> We could also do the same thing for Linux et al.
>   

On Linux, I guess we could readlink(/proc/self/exe), but I don't know 
what we could do on other OSes.  In general, argv[0] isn't very useful.

What I had suggested to someone a while back, was that first, we should 
refactor things so that we can try to read all of the bios/keymap files 
from a number of paths.  That way, we could try the current path, the -L 
path, the path of the exe, etc.   The only problem with that it can 
become confusing trying to figure out what bios you are using.

Regards,

Anthony Liguori

> Paul
>   

Re: [Qemu-devel] [5524] Fix windows build after migration changes

[Andreas Färber]

Am 24.10.2008 um 17:37 schrieb Paul Brook:

> On Friday 24 October 2008, Anthony Liguori wrote:
>> Robert Riebisch wrote:
>>> Anthony Liguori wrote:
>>>> That would be great.  I don't know that we want to go on the  
>>>> current
>>>> directory though.  There's a Windows API for finding Program Files.
>>>> That's probably what we want to do.
>>>
>>> Why do you want to look for "Program Files" instead? Just let QEMU
>>> determine its own folder via GetModuleFileName() and look there  
>>> for the
>>> BIOS files.
>>
>> That's not the same as CWD and is probably the right thing to do.
>
> We could also do the same thing for Linux et al.

On Linux et al. the BIOS usually does not live where the binary is, no?
(e.g., bin vs. share)

For instance, on Solaris a 64-bit QEMU might want to live in $prefix/ 
bin/amd64 but could use a non-amd64-specific BIOS. The relative  
path ../share/qemu/ from the binary's location would not work then;  
hardcoding via configure (but letting the user override) seems nicer  
on non-Windows and is quite common for autoconf-based projects.

Andreas