Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

Hi,

On Thu, 30 Aug 2007, Thiemo Seufer wrote:

  * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
 to deal with the relocs resulting from using section anchors
 
 Maybe this should be handled more generally then, not ppc specific, like
 other offending compiler options: check if the compiler knows the
 option, if yes, disable the feature.

Yeah, like is done for the other additions to OP_CFLAGS, which are guarded 
by $(call cc-option, ...).

 I solved that by placing one of the T[012] operands into memory
 for HOST_I386, thereby freeing one reg.  Here's some justification 
 of why that doesn't really cost performance: with three free regs
 GCC is already spilling like mad in the snippets, we just trade one
 of those memory accesses (to stack) with one other mem access to 
 the cpu_state structure, which will be in cache.
 
 Could you back up this assumption with some numbers? :-)

I did that downthread.  To me the slowdown is not significant enough, 
although it exists.

  --- qemu-0.9.0.cvs.orig/target-arm/cpu.h2007-06-24 14:09:48.0 
  +0200
  +++ qemu-0.9.0.cvs/target-arm/cpu.h 2007-08-21 21:38:36.0 +0200
  @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
*/
   
   typedef struct CPUARMState {
  +#if defined(HOST_I386)
  +uint32_t t1;
  +#endif
   /* Regs for current mode.  */
   uint32_t regs[16];
   /* Frequently accessed CPSR bits are stored separately for efficiently.
  diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h 
  qemu-0.9.0.cvs/target-arm/exec.h
  --- qemu-0.9.0.cvs.orig/target-arm/exec.h   2007-06-03 19:44:36.0 
  +0200
  +++ qemu-0.9.0.cvs/target-arm/exec.h2007-08-21 21:48:48.0 
  +0200
  @@ -23,7 +23,12 @@
   register struct CPUARMState *env asm(AREG0);
   register uint32_t T0 asm(AREG1);
   register uint32_t T1 asm(AREG2);
  +#ifndef HOST_I386
   register uint32_t T2 asm(AREG3);
  +#else
  +#define T2 (env-t1)
  +#endif
 
 T2/t1 mismatch, it seems. Likewise for mips and ppc.

Yes, well, I could have named the env member perhaps temp :-)  I can 
change it, though.


Ciao,
Michael.

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Thiemo Seufer]

Michael Matz wrote:
 Hi,
 
 On Thu, 30 Aug 2007, Thiemo Seufer wrote:
 
   * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
  to deal with the relocs resulting from using section anchors
  
  Maybe this should be handled more generally then, not ppc specific, like
  other offending compiler options: check if the compiler knows the
  option, if yes, disable the feature.
 
 Yeah, like is done for the other additions to OP_CFLAGS, which are guarded 
 by $(call cc-option, ...).
 
  I solved that by placing one of the T[012] operands into memory
  for HOST_I386, thereby freeing one reg.  Here's some justification 
  of why that doesn't really cost performance: with three free regs
  GCC is already spilling like mad in the snippets, we just trade one
  of those memory accesses (to stack) with one other mem access to 
  the cpu_state structure, which will be in cache.
  
  Could you back up this assumption with some numbers? :-)
 
 I did that downthread.  To me the slowdown is not significant enough, 
 although it exists.

I would like to have it conditional on GCC4.

   --- qemu-0.9.0.cvs.orig/target-arm/cpu.h  2007-06-24 14:09:48.0 
   +0200
   +++ qemu-0.9.0.cvs/target-arm/cpu.h   2007-08-21 21:38:36.0 
   +0200
   @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
 */

typedef struct CPUARMState {
   +#if defined(HOST_I386)
   +uint32_t t1;
   +#endif
/* Regs for current mode.  */
uint32_t regs[16];
/* Frequently accessed CPSR bits are stored separately for 
   efficiently.
   diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h 
   qemu-0.9.0.cvs/target-arm/exec.h
   --- qemu-0.9.0.cvs.orig/target-arm/exec.h 2007-06-03 19:44:36.0 
   +0200
   +++ qemu-0.9.0.cvs/target-arm/exec.h  2007-08-21 21:48:48.0 
   +0200
   @@ -23,7 +23,12 @@
register struct CPUARMState *env asm(AREG0);
register uint32_t T0 asm(AREG1);
register uint32_t T1 asm(AREG2);
   +#ifndef HOST_I386
register uint32_t T2 asm(AREG3);
   +#else
   +#define T2 (env-t1)
   +#endif
  
  T2/t1 mismatch, it seems. Likewise for mips and ppc.
 
 Yes, well, I could have named the env member perhaps temp :-)  I can 
 change it, though.

I did expect T2 to map to env-t2, like it is done for 64bit-emu on
32bit-host. It keeps things a bit more comprehensible. :-)


Thiemo

[Qemu-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Jorge Lucángeli Obes]

Hi all,

The last time this issue was discussed, the executable-directory idea
gained more consensus than the snapshot-based idea. This patch
implements my perception of the first idea. Non-Windows for now, as I
can't test on a Windows system. Suggestions and constructive criticism
more than welcome.

Cheers,
Jorge

This patch allows QEMU to execute a directory with a special format.

This patch allows storing command line options in a configuration file inside
a directory and then directly executing that directory. A simple check is
included to prevent the configuration file to access image files outside
the executed directory. Extra command line options can be passed on invocation,
which will take precedence over the ones stored in the configuration file.

The configuration file specifies, on its first line, the image file to use.
The rest of the file specifies command line options separated by spaces or
newlines. Careful reconstruction of the command line makes sure the speficied
image file gets executed even if other image files were included later in the
configuration file.

Signed-off-by: Jorge Lucángeli Obes
---
diff --git a/qemu/vl.c b/qemu/vl.c
index fcc899b..88cefd2 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -42,8 +42,8 @@
 #include netinet/in.h
 #include dirent.h
 #include netdb.h
-#ifdef _BSD
 #include sys/stat.h
+#ifdef _BSD
 #ifndef __APPLE__
 #include libutil.h
 #endif
@@ -6367,9 +6367,16 @@ int main_loop(void)
 void help(void)
 {
 printf(QEMU PC emulator version  QEMU_VERSION , Copyright (c)
2003-2007 Fabrice Bellard\n
-   usage: %s [options] [disk_image]\n
+   usage: %s [options] [disk_image|folder]\n
\n
+#ifdef _WIN32
'disk_image' is a raw hard image image for IDE hard disk 0\n
+#else
+   'disk_image' is a raw hard image image for IDE hard disk 0 or\n
+   'folder' is a folder with a file 'config' containing in
the first line\n
+   the name of an image file inside the folder and in the
rest of the file\n
+   options separated by ' ' or '\\n'\n
+#endif
\n
Standard options:\n
-M machine  select emulated machine (-M ? for list)\n
@@ -6892,6 +6899,20 @@ void qemu_get_launch_info(int *argc, char
***argv, int *opt_daemonize, const cha
 *opt_incoming = incoming;
 }

+char *dir_file_cat(const char *folder, const char *file) {
+int foldlen = strlen(folder);
+int filelen = strlen(file);
+int reslen = foldlen + 1 + filelen + 1;
+
+char *res = malloc(sizeof(char) * reslen);
+
+pstrcpy(res, reslen, folder);
+strncat(res, /, 1);
+strncat(res, file, filelen);
+
+return res;
+}
+
 int main(int argc, char **argv)
 {
 #ifdef CONFIG_GDBSTUB
@@ -7003,7 +7024,120 @@ int main(int argc, char **argv)

 nb_nics = 0;
 /* default mac address of the first network interface */
+
+#ifndef _WIN32
+#define DIR_CMDLINE_SIZE 113
+int hd_found = 0;
+char *dir, *opts;
+struct stat *s = NULL;
+
+optind = 1;
+for(;;) {
+if (optind = argc)
+break;
+
+dir = argv[optind++];
+
+if (dir[0] != '-') {
+hd_found = 1;
+break;
+}
+}

+if (hd_found) {
+s = malloc(sizeof(*s));
+
+if (stat(dir, s)  0) {
+/* Error */
+fprintf(stderr, unable to stat: '%s'\n,
+dir);
+exit(1);
+}
+
+if (S_ISDIR(s-st_mode)) {
+/* The user specified a directory, search for ./config */
+int configlen = strlen(dir);
+configlen += 8; /* /config\0 */
+char *config = malloc(sizeof(char) * configlen);
+
+pstrcpy(config, configlen, dir);
+strncat(config, /config, 7);
+
+int fd_config;
+
+if ((fd_config = open(config, 0))  0) {
+/* Error */
+if (errno == ENOENT)
+fprintf(stderr, config file not found: '%s'\n,
+config);
+else
+fprintf(stderr, unable to open config file: '%s'\n,
+config);
+exit(1);
+}
+
+opts = malloc(sizeof(char) * (DIR_CMDLINE_SIZE));
+
+ssize_t readb = read(fd_config, opts, (DIR_CMDLINE_SIZE) - 1);
+
+opts[readb] = '\0';
+
+char *filename = strsep(opts, \n);
+
+if (filename == NULL) {
+/* Error */
+fprintf(stderr, malformed configuration file: '%s'\n,
+config);
+exit(1);
+} else if (strchr(filename, '/') != NULL) {
+/* Error */
+fprintf(stderr, '%s' may point outside folder '%s'\n
+avoid using '/' in config file\n,
+filename, dir);
+exit(1);
+}
+
+char tmpopts[DIR_CMDLINE_SIZE];
+  

[Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Anthony Liguori]

It makes little sense to pass a directory when you can pass a config
file and assume that the directory the config file is in is the CWD.

For instance, if vm.cfg contained just the command line arguments, you
could have:

MyImage/vm.cfg:-hda disk0.qcow -m 512
MyImage/disk0.qcow:disk image

And then do:

qemu -c MyImage/vm.cfg

Regards,

Anthony Liguori


On Fri, 2007-08-31 at 15:19 -0300, Jorge Lucángeli Obes wrote:
 Hi all,
 
 The last time this issue was discussed, the executable-directory idea
 gained more consensus than the snapshot-based idea. This patch
 implements my perception of the first idea. Non-Windows for now, as I
 can't test on a Windows system. Suggestions and constructive criticism
 more than welcome.
 
 Cheers,
 Jorge
 
 This patch allows QEMU to execute a directory with a special format.
 
 This patch allows storing command line options in a configuration file inside
 a directory and then directly executing that directory. A simple check is
 included to prevent the configuration file to access image files outside
 the executed directory. Extra command line options can be passed on 
 invocation,
 which will take precedence over the ones stored in the configuration file.
 
 The configuration file specifies, on its first line, the image file to use.
 The rest of the file specifies command line options separated by spaces or
 newlines. Careful reconstruction of the command line makes sure the speficied
 image file gets executed even if other image files were included later in the
 configuration file.
 
 Signed-off-by: Jorge Lucángeli Obes
 ---
 diff --git a/qemu/vl.c b/qemu/vl.c
 index fcc899b..88cefd2 100644
 --- a/qemu/vl.c
 +++ b/qemu/vl.c
 @@ -42,8 +42,8 @@
  #include netinet/in.h
  #include dirent.h
  #include netdb.h
 -#ifdef _BSD
  #include sys/stat.h
 +#ifdef _BSD
  #ifndef __APPLE__
  #include libutil.h
  #endif
 @@ -6367,9 +6367,16 @@ int main_loop(void)
  void help(void)
  {
  printf(QEMU PC emulator version  QEMU_VERSION , Copyright (c)
 2003-2007 Fabrice Bellard\n
 -   usage: %s [options] [disk_image]\n
 +   usage: %s [options] [disk_image|folder]\n
 \n
 +#ifdef _WIN32
 'disk_image' is a raw hard image image for IDE hard disk 0\n
 +#else
 +   'disk_image' is a raw hard image image for IDE hard disk 0 or\n
 +   'folder' is a folder with a file 'config' containing in
 the first line\n
 +   the name of an image file inside the folder and in the
 rest of the file\n
 +   options separated by ' ' or '\\n'\n
 +#endif
 \n
 Standard options:\n
 -M machine  select emulated machine (-M ? for list)\n
 @@ -6892,6 +6899,20 @@ void qemu_get_launch_info(int *argc, char
 ***argv, int *opt_daemonize, const cha
  *opt_incoming = incoming;
  }
 
 +char *dir_file_cat(const char *folder, const char *file) {
 +int foldlen = strlen(folder);
 +int filelen = strlen(file);
 +int reslen = foldlen + 1 + filelen + 1;
 +
 +char *res = malloc(sizeof(char) * reslen);
 +
 +pstrcpy(res, reslen, folder);
 +strncat(res, /, 1);
 +strncat(res, file, filelen);
 +
 +return res;
 +}
 +
  int main(int argc, char **argv)
  {
  #ifdef CONFIG_GDBSTUB
 @@ -7003,7 +7024,120 @@ int main(int argc, char **argv)
 
  nb_nics = 0;
  /* default mac address of the first network interface */
 +
 +#ifndef _WIN32
 +#define DIR_CMDLINE_SIZE 113
 +int hd_found = 0;
 +char *dir, *opts;
 +struct stat *s = NULL;
 +
 +optind = 1;
 +for(;;) {
 +if (optind = argc)
 +break;
 +
 +dir = argv[optind++];
 +
 +if (dir[0] != '-') {
 +hd_found = 1;
 +break;
 +}
 +}
 
 +if (hd_found) {
 +s = malloc(sizeof(*s));
 +
 +if (stat(dir, s)  0) {
 +/* Error */
 +fprintf(stderr, unable to stat: '%s'\n,
 +dir);
 +exit(1);
 +}
 +
 +if (S_ISDIR(s-st_mode)) {
 +/* The user specified a directory, search for ./config */
 +int configlen = strlen(dir);
 +configlen += 8; /* /config\0 */
 +char *config = malloc(sizeof(char) * configlen);
 +
 +pstrcpy(config, configlen, dir);
 +strncat(config, /config, 7);
 +
 +int fd_config;
 +
 +if ((fd_config = open(config, 0))  0) {
 +/* Error */
 +if (errno == ENOENT)
 +fprintf(stderr, config file not found: '%s'\n,
 +config);
 +else
 +fprintf(stderr, unable to open config file: '%s'\n,
 +config);
 +exit(1);
 +}
 +
 +opts = malloc(sizeof(char) * (DIR_CMDLINE_SIZE));
 +
 +ssize_t readb = read(fd_config, opts, (DIR_CMDLINE_SIZE) - 1);
 +
 +opts[readb] = '\0';
 +
 +char 

Re: [Qemu-devel] disk images driver geometry

[Christopher Friedt]

Anthony Liguori wrote:
I have no idea what you're talking about.  QEMU doesn't care whether you 
use a physical disk or a file.  It handles geometry the same way.


Is there a concrete example that doesn't work that you think should?


Yes, a simple example is running CentOS after a typical install from a 
hard disk image.


If Qemu is started with the installation cdrom (-cdrom CentOS-1of4*.iso) 
the installation creates several partitions on the virtual disk, 
including /boot, and a logical disk containing /. The first 512 Bytes of 
the disk image are assumed to be the MBR of the disk, which is where the 
installation will write the boot loader.


After installation, qemu is started with

qemu -hda centos.img -boot c

and it hangs after saying 'booting from hard disk'

If anyone knows a way to work around this, please don't hesitate to 
offer a suggestion.


~/Chris

[Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Anthony Liguori]

On Fri, 2007-08-31 at 16:05 -0300, Jorge Lucángeli Obes wrote:
 On 8/31/07, Anthony Liguori [EMAIL PROTECTED] wrote:
  It makes little sense to pass a directory when you can pass a config
  file and assume that the directory the config file is in is the CWD.
 
  For instance, if vm.cfg contained just the command line arguments, you
  could have:
 
  MyImage/vm.cfg:-hda disk0.qcow -m 512
  MyImage/disk0.qcow:disk image
 
  And then do:
 
  qemu -c MyImage/vm.cfg
 
 I thought about this when coding, and it's true. Maybe we could just
 leave a new explicit config file option. I insist on making this as
 simple as possible, that's why I  chose to use the config file as a
 written-down command line.
 
 If this were the case, we could remove the restriction of having the
 config file refer only to images on the same directory, as the use of
 the config file would be explicit. Thoughts?

Yes.  It should be a very simple patch.

Regards,

Anthony Liguori

 Cheers,
 Jorge

Re: [Qemu-devel] disk images driver geometry

[Anthony Liguori]

On Fri, 2007-08-31 at 15:09 -0400, Christopher Friedt wrote:
 Anthony Liguori wrote:
  I have no idea what you're talking about.  QEMU doesn't care whether you 
  use a physical disk or a file.  It handles geometry the same way.
  
  Is there a concrete example that doesn't work that you think should?
 
 Yes, a simple example is running CentOS after a typical install from a 
 hard disk image.
 
 If Qemu is started with the installation cdrom (-cdrom CentOS-1of4*.iso) 
 the installation creates several partitions on the virtual disk, 
 including /boot, and a logical disk containing /. The first 512 Bytes of 
 the disk image are assumed to be the MBR of the disk, which is where the 
 installation will write the boot loader.
 
 After installation, qemu is started with
 
 qemu -hda centos.img -boot c
 
 and it hangs after saying 'booting from hard disk'

QEMU does the Right Thing in this case.  If you're having trouble
booting, it's not because of disk geometry.

Please post a link to the exact location of your install disk, the
command you used to create the disk, the command lines you're using to
install and launch, and the version of QEMU.

Regards,

Anthony Liguori

 If anyone knows a way to work around this, please don't hesitate to 
 offer a suggestion.
 
 ~/Chris
 
 

Re: [Qemu-devel] Build failure on OS X - dynticks

[Luca Tettamanti]

Andreas Färber ha scritto:
 Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:

 One of the recent patches (dynticks) has broken compilation on Mac
 OS X v10.4. Should this work on OS X or should this have been
 limited to Linux?

 Getting no answer on this I have prepared a quickfix which wraps all
 dynticks in conditional sections for __linux__, restoring compilation
 on OS X.
 If this is the right way to fix then the conditional sections can be
 merged with HPET, which is already limited to __linux__.

Sorry for the late reply, I totaly missed you mail. The timers I've used
are POSIX and are supported on *BSD so I guessed they would work on OSX
too... cleary that's not the case.
Can you grep the headers for timer_create? Maybe the prototypes are in a
different file.

Luca
-- 
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

Re: [Qemu-devel] Build failure on OS X - dynticks

[Andreas Färber]

Am 31.08.2007 um 21:45 schrieb Luca Tettamanti:


Andreas Färber ha scritto:

Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:


One of the recent patches (dynticks) has broken compilation on Mac
OS X v10.4. Should this work on OS X or should this have been
limited to Linux?


Getting no answer on this I have prepared a quickfix which wraps all
dynticks in conditional sections for __linux__, restoring compilation
on OS X.


Sorry for the late reply, I totaly missed you mail. The timers I've  
used
are POSIX and are supported on *BSD so I guessed they would work on  
OSX

too... cleary that's not the case.
Can you grep the headers for timer_create? Maybe the prototypes are  
in a

different file.


I had that thought myself but man had nothing on it and Spotlight  
didn't find anything apart from Qemu itself.


Andreas

[Qemu-devel] Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[laurent . vivier]

Hi Anthony,

I think passing only the directory name is better because it can be like a
black box : the user don't have to know how it is inside. And it is much
more simple to use qemu my_pc than qemu -c my_pc/config.

Regards,
Laurent

--
  Pour :  Jorge Lucángeli Obes [EMAIL PROTECTED]
  cc :  [EMAIL PROTECTED], qemu-devel@nongnu.org
  ccc :
  Objet : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly
execute a directory (and storing command line options in it)
Anthony Liguori [EMAIL PROTECTED]
Envoyé par : [EMAIL PROTECTED]
31/08/2007 13:54 EST
font size=-1/font



















It makes little sense to pass a directory when you can pass a config
file and assume that the directory the config file is in is the CWD.

For instance, if vm.cfg contained just the command line arguments, you
could have:

MyImage/vm.cfg:-hda disk0.qcow -m 512
MyImage/disk0.qcow:disk image

And then do:

qemu -c MyImage/vm.cfg

Re: [Qemu-devel] Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Johannes Schindelin]

Hi,

On Fri, 31 Aug 2007, [EMAIL PROTECTED] wrote:

 I think passing only the directory name is better because it can be like 
 a black box : the user don't have to know how it is inside.

I consider this a super downside.

If you think your users are idiots, only idiots will use it [your 
software].

 And it is much more simple to use qemu my_pc than qemu -c 
 my_pc/config.

_Much_ more simple?  Not really.

Having said that, it should not be a big problem to change the source just 
for _you_, so that if my_pc could not be opened, it automatically tries 
my_pc/config.  Trivial.

Ciao,
Dscho

Réf. : Re: [Qemu-devel] Réf. : Re: [kvm -devel] [PATCH ][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[laurent . vivier]

 Hi,

 On Fri, 31 Aug 2007, [EMAIL PROTECTED] wrote:

  I think passing only the directory name is better because it can be
like
  a black box : the user don't have to know how it is inside.

 I consider this a super downside.

 If you think your users are idiots, only idiots will use it [your
software].

But I'm idiot (and lazy) and I'd like to use it...

  And it is much more simple to use qemu my_pc than qemu -c
  my_pc/config.

 _Much_ more simple?  Not really.

 Having said that, it should not be a big problem to change the source
just
 for _you_, so that if my_pc could not be opened, it automatically tries
 my_pc/config.  Trivial.

Agree

Laurent

Re: [Qemu-devel] Build failure on OS X - dynticks

[Luca]

On 8/31/07, Andreas Färber [EMAIL PROTECTED] wrote:

 Am 31.08.2007 um 21:45 schrieb Luca Tettamanti:

  Andreas Färber ha scritto:
  Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:
 
  One of the recent patches (dynticks) has broken compilation on Mac
  OS X v10.4. Should this work on OS X or should this have been
  limited to Linux?
 
  Getting no answer on this I have prepared a quickfix which wraps all
  dynticks in conditional sections for __linux__, restoring compilation
  on OS X.
 
  Sorry for the late reply, I totaly missed you mail. The timers I've
  used
  are POSIX and are supported on *BSD so I guessed they would work on
  OSX
  too... cleary that's not the case.
  Can you grep the headers for timer_create? Maybe the prototypes are
  in a
  different file.

 I had that thought myself but man had nothing on it and Spotlight
 didn't find anything apart from Qemu itself.

Oh well, your patch is fine then.

Luca

[Qemu-devel] Re: Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Anthony Liguori]

On Fri, 2007-08-31 at 22:13 +0200, [EMAIL PROTECTED] wrote:
 Hi Anthony,
 
 I think passing only the directory name is better because it can be like a
 black box : the user don't have to know how it is inside. And it is much
 more simple to use qemu my_pc than qemu -c my_pc/config.

You're overriding what qemu my_pc means.  qemu my_pc create a QEMU
vm with 128m of memory and -hda my_pc with the default network card.

qemu -c my_pc/config only has one meaning: read command line arguments
from my_pc/config.

Your suggested syntax may be simpler for your particular use-case, but
it makes QEMU much more difficult to understand for every other user.

Regards,

Anthony Liguori

 Regards,
 Laurent
 
 --
   Pour :  Jorge Lucángeli Obes [EMAIL PROTECTED]
   cc :  [EMAIL PROTECTED], qemu-devel@nongnu.org
   ccc :
   Objet : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly
 execute a directory (and storing command line options in it)
 Anthony Liguori [EMAIL PROTECTED]
 Envoyé par : [EMAIL PROTECTED]
 31/08/2007 13:54 EST
 font size=-1/font
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 It makes little sense to pass a directory when you can pass a config
 file and assume that the directory the config file is in is the CWD.
 
 For instance, if vm.cfg contained just the command line arguments, you
 could have:
 
 MyImage/vm.cfg:-hda disk0.qcow -m 512
 MyImage/disk0.qcow:disk image
 
 And then do:
 
 qemu -c MyImage/vm.cfg
 
 
 
 
 
 

[Qemu-devel] Re: [kvm-devel] Réf. : Re: [PATCH][RFC] A llowing QEMU to directly executeadirectory (and storing command line options in it)

[Daniel P. Berrange]

On Fri, Aug 31, 2007 at 10:13:11PM +0200, [EMAIL PROTECTED] wrote:
 I think passing only the directory name is better because it can be like a
 black box : the user don't have to know how it is inside. And it is much
 more simple to use qemu my_pc than qemu -c my_pc/config.

If you need this incredible 'simplicity', a 1 line shell script can easily
provide it for you;

$ cat myqemu
#!/bin/sh
exec qemu -c $1/config

One of the great strengths of QEMU is its predictability - it may have a
huge number of command line args, but this is exactly what gives QEMU such
power  utility. It makes it very straightforward to build applications
around QEMU, and ensure it behaviours in a 100% reliable  predictable manner.
We should be wary of putting policy  heuristics into QEMU to turn it into
a 'black box' because that will compromise the use cases at which it currently
excels. A simple '-c' arg which takes a path to a config file is more than
sufficient, without needing heuristics to look for magical named files in
directories.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Re: Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Luke -Jr]

On Friday 31 August 2007, Anthony Liguori wrote:
 You're overriding what qemu my_pc means.  qemu my_pc create a QEMU
 vm with 128m of memory and -hda my_pc with the default network card.

Why should -hda be assumed instead of -c or -c X/config?

 qemu -c my_pc/config only has one meaning: read command line arguments
 from my_pc/config.

Likewise, qemu -hda my_pc also only has one meaning.