[Qemu-devel] QEMU/pc and scsi disks

[Qemu-devel] QEMU/pc and scsi disks

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 388 bytes --]

Hi,

As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but I
propose a little patch to make SCSI disks visible. Disks are not bootable, I
think we should write a BIOS for that ?

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
       "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke

[-- Attachment #1.2: pc-scsidisk.diff --]
[-- Type: text/plain, Size: 6131 bytes --]

Index: qemu-0.9.0/hw/lsi53c895a.c
===================================================================
--- qemu-0.9.0.orig/hw/lsi53c895a.c	2007-03-01 17:53:43.000000000 +0100
+++ qemu-0.9.0/hw/lsi53c895a.c	2007-03-01 17:54:43.000000000 +0100
@@ -149,9 +149,6 @@
 #define PHASE_MI          7
 #define PHASE_MASK        7
 
-/* The HBA is ID 7, so for simplicitly limit to 7 devices.  */
-#define LSI_MAX_DEVS      7
-
 /* Maximum length of MSG IN data.  */
 #define LSI_MAX_MSGIN_LEN 8
 
Index: qemu-0.9.0/vl.h
===================================================================
--- qemu-0.9.0.orig/vl.h	2007-03-01 17:53:43.000000000 +0100
+++ qemu-0.9.0/vl.h	2007-03-01 17:54:43.000000000 +0100
@@ -917,7 +917,10 @@
 /* ide.c */
 #define MAX_DISKS 4
 
-extern BlockDriverState *bs_table[MAX_DISKS + 1];
+/* lsi53c895a.c */
+#define LSI_MAX_DEVS 7
+
+extern BlockDriverState *bs_table[MAX_DISKS + LSI_MAX_DEVS + 1];
 
 void isa_ide_init(int iobase, int iobase2, int irq,
                   BlockDriverState *hd0, BlockDriverState *hd1);
Index: qemu-0.9.0/vl.c
===================================================================
--- qemu-0.9.0.orig/vl.c	2007-03-01 17:53:43.000000000 +0100
+++ qemu-0.9.0/vl.c	2007-03-01 17:54:43.000000000 +0100
@@ -121,7 +121,7 @@
 IOPortWriteFunc *ioport_write_table[3][MAX_IOPORTS];
 /* Note: bs_table[MAX_DISKS] is a dummy block driver if none available
    to store the VM snapshots */
-BlockDriverState *bs_table[MAX_DISKS + 1], *fd_table[MAX_FD];
+BlockDriverState *bs_table[MAX_DISKS + LSI_MAX_DEVS + 1], *fd_table[MAX_FD];
 /* point to the block driver where the snapshots are managed */
 BlockDriverState *bs_snapshots;
 int vga_ram_size;
@@ -6020,6 +6020,7 @@
            "-fda/-fdb file  use 'file' as floppy disk 0/1 image\n"
            "-hda/-hdb file  use 'file' as IDE hard disk 0/1 image\n"
            "-hdc/-hdd file  use 'file' as IDE hard disk 2/3 image\n"
+           "-sda..-sdg file use 'file' as SCSI hard disk 0 to 7 image\n"
            "-cdrom file     use 'file' as IDE cdrom image (cdrom is ide1 master)\n"
            "-boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM (d), or network (n)\n"
            "-snapshot       write to temporary files instead of disk image files\n"
@@ -6154,6 +6155,13 @@
     QEMU_OPTION_hdc,
     QEMU_OPTION_hdd,
     QEMU_OPTION_cdrom,
+    QEMU_OPTION_sda,
+    QEMU_OPTION_sdb,
+    QEMU_OPTION_sdc,
+    QEMU_OPTION_sdd,
+    QEMU_OPTION_sde,
+    QEMU_OPTION_sdf,
+    QEMU_OPTION_sdg,
     QEMU_OPTION_boot,
     QEMU_OPTION_snapshot,
 #ifdef TARGET_I386
@@ -6226,6 +6234,13 @@
     { "hdc", HAS_ARG, QEMU_OPTION_hdc },
     { "hdd", HAS_ARG, QEMU_OPTION_hdd },
     { "cdrom", HAS_ARG, QEMU_OPTION_cdrom },
+    { "sda", HAS_ARG, QEMU_OPTION_sda },
+    { "sdb", HAS_ARG, QEMU_OPTION_sdb },
+    { "sdc", HAS_ARG, QEMU_OPTION_sdc },
+    { "sdd", HAS_ARG, QEMU_OPTION_sdd },
+    { "sde", HAS_ARG, QEMU_OPTION_sde },
+    { "sdf", HAS_ARG, QEMU_OPTION_sdf },
+    { "sdg", HAS_ARG, QEMU_OPTION_sdg },
     { "boot", HAS_ARG, QEMU_OPTION_boot },
     { "snapshot", 0, QEMU_OPTION_snapshot },
 #ifdef TARGET_I386
@@ -6504,6 +6519,7 @@
     int i, cdrom_index;
     int snapshot, linux_boot;
     const char *initrd_filename;
+    const char *sd_filename[LSI_MAX_DEVS];
     const char *hd_filename[MAX_DISKS], *fd_filename[MAX_FD];
     const char *kernel_filename, *kernel_cmdline;
     DisplayState *ds = &display_state;
@@ -6562,6 +6578,8 @@
         fd_filename[i] = NULL;
     for(i = 0; i < MAX_DISKS; i++)
         hd_filename[i] = NULL;
+    for(i = 0; i < LSI_MAX_DEVS; i++)
+        sd_filename[i] = NULL;
     ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
     vga_ram_size = VGA_RAM_SIZE;
     bios_size = BIOS_SIZE;
@@ -6664,6 +6682,15 @@
                         cdrom_index = -1;
                 }
                 break;
+	    case QEMU_OPTION_sda:
+	    case QEMU_OPTION_sdb:
+	    case QEMU_OPTION_sdc:
+	    case QEMU_OPTION_sdd:
+	    case QEMU_OPTION_sde:
+	    case QEMU_OPTION_sdf:
+	    case QEMU_OPTION_sdg:
+                sd_filename[popt->index - QEMU_OPTION_sda] = optarg;
+                break;
             case QEMU_OPTION_snapshot:
                 snapshot = 1;
                 break;
@@ -7123,7 +7150,22 @@
             }
         }
     }
-
+    for( i = 0; i < LSI_MAX_DEVS; i++) {
+        int ret;
+	if (sd_filename[i]) {
+	    if (!bs_table[i + MAX_DISKS]) {
+		char buf[64];
+		snprintf(buf, sizeof(buf), "sd%c", i + 'a');
+		bs_table[i + MAX_DISKS] = bdrv_new(buf);
+	    }
+	    ret = bdrv_open(bs_table[i + MAX_DISKS], sd_filename[i], 0);
+	    if (ret < 0) {
+	        fprintf(stderr, "qemu: could not open hard disk image '%s'\n",
+			sd_filename[i]);
+		exit(1);
+	    }
+	}
+    }
     /* we always create at least one floppy disk */
     fd_table[0] = bdrv_new("fda");
     bdrv_set_type_hint(fd_table[0], BDRV_TYPE_FLOPPY);
Index: qemu-0.9.0/hw/pc.c
===================================================================
--- qemu-0.9.0.orig/hw/pc.c	2007-03-01 17:55:05.000000000 +0100
+++ qemu-0.9.0/hw/pc.c	2007-03-01 17:55:13.000000000 +0100
@@ -711,23 +711,16 @@
     if (i440fx_state) {
         i440fx_init_memory_mappings(i440fx_state);
     }
-#if 0
-    /* ??? Need to figure out some way for the user to
-       specify SCSI devices.  */
+
     if (pci_enabled) {
         void *scsi;
-        BlockDriverState *bdrv;
 
         scsi = lsi_scsi_init(pci_bus, -1);
-        bdrv = bdrv_new("scsidisk");
-        bdrv_open(bdrv, "scsi_disk.img", 0);
-        lsi_scsi_attach(scsi, bdrv, -1);
-        bdrv = bdrv_new("scsicd");
-        bdrv_open(bdrv, "scsi_cd.iso", 0);
-        bdrv_set_type_hint(bdrv, BDRV_TYPE_CDROM);
-        lsi_scsi_attach(scsi, bdrv, -1);
+	for (i = 0; i < LSI_MAX_DEVS; i++) {
+	    if (bs_table[i + MAX_DISKS])
+        	lsi_scsi_attach(scsi, bs_table[i + MAX_DISKS], -1);
+	}
     }
-#endif
 }
 
 static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] QEMU/pc and scsi disks

[Paul Brook]

On Thursday 01 March 2007 17:26, Laurent Vivier wrote:
> Hi,
>
> As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but
> I propose a little patch to make SCSI disks visible. 

See previous discussion about how the disk options need to be fixed properly.
Apart from anything else your patch completely ignores non-x86 targets. 
There's also no reason to limit to 7 disks, and we should support scsi 
cdroms.

Paul

Re: [Qemu-devel] QEMU/pc and scsi disks

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

Paul Brook wrote:
> On Thursday 01 March 2007 17:26, Laurent Vivier wrote:
>> Hi,
>>
>> As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but
>> I propose a little patch to make SCSI disks visible. 
> 
> See previous discussion about how the disk options need to be fixed properly.

Sorry, I didn't find it, but now I've found it.

> Apart from anything else your patch completely ignores non-x86 targets.

This patch was just to validate my approach... and it seems bad :-P

> There's also no reason to limit to 7 disks, and we should support scsi 
> cdroms.

The reason for 7 is the number of available id on the scsi bus. Of course, we
could manage several bus. To add cdroms support, we can add parameters "-scd0",
"-scd1", ...

Thank you for your comments.

Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
       "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] QEMU/pc and scsi disks

[Thiemo Seufer]

Laurent Vivier wrote:
> Paul Brook wrote:
> > On Thursday 01 March 2007 17:26, Laurent Vivier wrote:
> >> Hi,
> >>
> >> As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but
> >> I propose a little patch to make SCSI disks visible. 
> > 
> > See previous discussion about how the disk options need to be fixed properly.
> 
> Sorry, I didn't find it, but now I've found it.
> 
> > Apart from anything else your patch completely ignores non-x86 targets.
> 
> This patch was just to validate my approach... and it seems bad :-P
> 
> > There's also no reason to limit to 7 disks, and we should support scsi 
> > cdroms.
> 
> The reason for 7 is the number of available id on the scsi bus.

For wide scsi it is 15.

> Of course, we
> could manage several bus. To add cdroms support, we can add parameters "-scd0",
> "-scd1", ...

This gets unwieldy quickly.


Thiemo

Re: [Qemu-devel] QEMU/pc and scsi disks

[Paul Brook]

> > > There's also no reason to limit to 7 disks, and we should support scsi
> > > cdroms.
> >
> > The reason for 7 is the number of available id on the scsi bus.
>
> For wide scsi it is 15.

I wouldn't bet on wide scsi working.
For PCI based systems you can add more host adapters to get more devices. I 
haven't actually tested this, but it should work.

Paul

Re: [Qemu-devel] QEMU/pc and scsi disks

[Anthony Liguori]

Paul Brook wrote:
>>>> There's also no reason to limit to 7 disks, and we should support scsi
>>>> cdroms.
>>>>         
>>> The reason for 7 is the number of available id on the scsi bus.
>>>       
>> For wide scsi it is 15.
>>     
>
> I wouldn't bet on wide scsi working.
> For PCI based systems you can add more host adapters to get more devices. I 
> haven't actually tested this, but it should work.
>   

I think most people agree that we need a config file.  I haven't seen 
any comments on my config file patch though.

So, any comments on that patch?  Any requirements on a format?

Regards,

Anthony Liguori

> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   

Re: [Qemu-devel] QEMU/pc and scsi disks

[Joe Batt]

I disagree.  /bin/sh makes a very flexible config file format that I  
use.  I use it on win32, Linux and Mac OS X.

I would prefer that you write another cross platform shell, than  
another config file.  At least that way I could use the same config  
tool for more than one application.

Everytime this comes up, do I have to disagree again, so that my  
voice is not lost?

Any yes, adding features that I do not use increases the complexity  
and decreases the stability of the features I do use, so it would  
effect me.  I have the same feeling about embedding VNC  
authentication, the samba server, etc.

Joe

On Mar 2, 2007, at 11:24 AM, Anthony Liguori wrote:

> Paul Brook wrote:
>>>>> There's also no reason to limit to 7 disks, and we should  
>>>>> support scsi
>>>>> cdroms.
>>>>>
>>>> The reason for 7 is the number of available id on the scsi bus.
>>>>
>>> For wide scsi it is 15.
>>>
>>
>> I wouldn't bet on wide scsi working.
>> For PCI based systems you can add more host adapters to get more  
>> devices. I haven't actually tested this, but it should work.
>>
>
> I think most people agree that we need a config file.  I haven't  
> seen any comments on my config file patch though.
>
> So, any comments on that patch?  Any requirements on a format?
>
> Regards,
>
> Anthony Liguori
>
>> Paul
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU/pc and scsi disks

[Avi Kivity]

Anthony Liguori wrote:
>
> I think most people agree that we need a config file.  I haven't seen 
> any comments on my config file patch though.
>
> So, any comments on that patch?  Any requirements on a format?
>

1.  Any option should be settable either in the config file or command 
line.  In other words, the user should not be forced to use a config 
file.  This is useful for management programs who keep all options in an 
internal database, and for users who can experiment via a ^P edit edit 
edit <enter>.

2. The %(blah)s syntax is a bit ugly.  It's one of the few things in 
python I dislike.  I'd prefer ${blah} and ${blah:modifier}.

3. It would be nice to be able to embed a config file in a qcow3 format 
so that one can ship an image with some default options in one file.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] QEMU/pc and scsi disks

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> I think most people agree that we need a config file.  I haven't seen 
>> any comments on my config file patch though.
>>
>> So, any comments on that patch?  Any requirements on a format?
>>
>
> 1.  Any option should be settable either in the config file or command 
> line.  In other words, the user should not be forced to use a config 
> file.  This is useful for management programs who keep all options in 
> an internal database, and for users who can experiment via a ^P edit 
> edit edit <enter>.

I think we should still provide the ability to set the most common 
options via the command line.  I'm also fine with specifying single 
options on the command line.  I suspect though that being able to do 
-config - is more useful for management tools than building large 
strings of command line options.

> 2. The %(blah)s syntax is a bit ugly.  It's one of the few things in 
> python I dislike.  I'd prefer ${blah} and ${blah:modifier}.

Yeah, I've never liked their printf syntax.  I was interested in 
interpolation, the syntax really doesn't matter to me.  sh is probably a 
bit easier on the eyes.

> 3. It would be nice to be able to embed a config file in a qcow3 
> format so that one can ship an image with some default options in one 
> file.

Yeah, definitely.

Regards,

Anthony Liguor

Re: [Qemu-devel] QEMU/pc and scsi disks

[Avi Kivity]

Anthony Liguori wrote:
>>
>> 1.  Any option should be settable either in the config file or 
>> command line.  In other words, the user should not be forced to use a 
>> config file.  This is useful for management programs who keep all 
>> options in an internal database, and for users who can experiment via 
>> a ^P edit edit edit <enter>.
>
> I think we should still provide the ability to set the most common 
> options via the command line.  I'm also fine with specifying single 
> options on the command line.  I suspect though that being able to do 
> -config - is more useful for management tools than building large 
> strings of command line options.

Out of curiosity, why?  If the options are store in some database, as is 
likely, surely it is easier to generate a longish command line than to 
generate a unique name for a file, remove it if it already exists, write 
out the data, launch qemu, and clean up the file later?  And for 
migration, you have to regenerate it, since some options may have 
changed (cdrom media).

Of course the config file is very useful for a user maintaining a few 
virtual machines on their own, but when qemu is part of a longer food 
chain, I think it's just a complication.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] QEMU/pc and scsi disks

[Paul Brook]

On Sunday 04 March 2007 09:28, Avi Kivity wrote:
> Anthony Liguori wrote:
> >> 1.  Any option should be settable either in the config file or
> >> command line.  In other words, the user should not be forced to use a
> >> config file.  This is useful for management programs who keep all
> >> options in an internal database, and for users who can experiment via
> >> a ^P edit edit edit <enter>.
> >
> > I think we should still provide the ability to set the most common
> > options via the command line.  I'm also fine with specifying single
> > options on the command line.  I suspect though that being able to do
> > -config - is more useful for management tools than building large
> > strings of command line options.
>
> Out of curiosity, why?  If the options are store in some database, as is
> likely, surely it is easier to generate a longish command line than to
> generate a unique name for a file, remove it if it already exists, write
> out the data, launch qemu, and clean up the file later?  And for
> migration, you have to regenerate it, since some options may have
> changed (cdrom media).

You're going to start hitting commandline length limits fairly rapidly 
(Windows in particular has a fairly low limit).

Paul

Re: [Qemu-devel] QEMU/pc and scsi disks

[Avi Kivity]

Paul Brook wrote:
>> Out of curiosity, why?  If the options are store in some database, as is
>> likely, surely it is easier to generate a longish command line than to
>> generate a unique name for a file, remove it if it already exists, write
>> out the data, launch qemu, and clean up the file later?  And for
>> migration, you have to regenerate it, since some options may have
>> changed (cdrom media).
>>     
>
> You're going to start hitting commandline length limits fairly rapidly 
> (Windows in particular has a fairly low limit).
>
>   

Well, at list on linux, the limit is sane (1024 or 10240?).


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] QEMU/pc and scsi disks

[Paul Brook]

On Sunday 04 March 2007 11:48, Avi Kivity wrote:
> Paul Brook wrote:
> >> Out of curiosity, why?  If the options are store in some database, as is
> >> likely, surely it is easier to generate a longish command line than to
> >> generate a unique name for a file, remove it if it already exists, write
> >> out the data, launch qemu, and clean up the file later?  And for
> >> migration, you have to regenerate it, since some options may have
> >> changed (cdrom media).
> >
> > You're going to start hitting commandline length limits fairly rapidly
> > (Windows in particular has a fairly low limit).
>
> Well, at list on linux, the limit is sane (1024 or 10240?).

IIRC linux has a ~32k commandline limit. I wouldn't be surprised if configs 
end up exceeding that.  If you're running on linux then creating a temporary 
file is also trivial[1].

Paul

[1] see mkstemp(3) and tmpfile(3).

Re: [Qemu-devel] QEMU/pc and scsi disks

[Chris Wilson]

Hi Avi,

On Sun, 4 Mar 2007, Avi Kivity wrote:
> Anthony Liguori wrote:
>>  I think we should still provide the ability to set the most common 
>>  options via the command line.  I'm also fine with specifying single 
>>  options on the command line.  I suspect though that being able to do 
>>  -config - is more useful for management tools than building large 
>>  strings of command line options.
>
> Out of curiosity, why?  If the options are store in some database, as is 
> likely, surely it is easier to generate a longish command line than to 
> generate a unique name for a file, remove it if it already exists, write out 
> the data, launch qemu, and clean up the file later?  And for migration, you 
> have to regenerate it, since some options may have changed (cdrom media).

I think Anthony was suggesting that "-config -" would read the config from 
standard input, avoiding the need for any temporary file, and also 
avoiding any command-line length limits on any platforms (Win32 is 
unlikely to accept as much as Linux).

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

Re: [Qemu-devel] QEMU/pc and scsi disks

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> 1.  Any option should be settable either in the config file or 
>>> command line.  In other words, the user should not be forced to use 
>>> a config file.  This is useful for management programs who keep all 
>>> options in an internal database, and for users who can experiment 
>>> via a ^P edit edit edit <enter>.
>>
>> I think we should still provide the ability to set the most common 
>> options via the command line.  I'm also fine with specifying single 
>> options on the command line.  I suspect though that being able to do 
>> -config - is more useful for management tools than building large 
>> strings of command line options.
>
> Out of curiosity, why?  If the options are store in some database, as 
> is likely, surely it is easier to generate a longish command line than 
> to generate a unique name for a file, remove it if it already exists, 
> write out the data, launch qemu, and clean up the file later?  And for 
> migration, you have to regenerate it, since some options may have 
> changed (cdrom media).

Sorry, I should have been more specific.  I mean '-config -' where '-' 
would indicate reading from stdin.

Regards,

Anthony Liguori

> Of course the config file is very useful for a user maintaining a few 
> virtual machines on their own, but when qemu is part of a longer food 
> chain, I think it's just a complication.
>

Re: [Qemu-devel] QEMU/pc and scsi disks

[Avi Kivity]

Chris Wilson wrote:
> Hi Avi,
>
> On Sun, 4 Mar 2007, Avi Kivity wrote:
>> Anthony Liguori wrote:
>>>  I think we should still provide the ability to set the most common 
>>>  options via the command line.  I'm also fine with specifying single 
>>>  options on the command line.  I suspect though that being able to 
>>> do  -config - is more useful for management tools than building 
>>> large  strings of command line options.
>>
>> Out of curiosity, why?  If the options are store in some database, as 
>> is likely, surely it is easier to generate a longish command line 
>> than to generate a unique name for a file, remove it if it already 
>> exists, write out the data, launch qemu, and clean up the file 
>> later?  And for migration, you have to regenerate it, since some 
>> options may have changed (cdrom media).
>
> I think Anthony was suggesting that "-config -" would read the config 
> from standard input, avoiding the need for any temporary file, and 
> also avoiding any command-line length limits on any platforms (Win32 
> is unlikely to accept as much as Linux).
>

Ah, I missed the '-'.  Thanks.  Indeed it's quite easy to feed a config 
file from memory into qemu.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] QEMU/pc and scsi disks

[Joseph Miller]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> I think most people agree that we need a config file.  I haven't seen 
>> any comments on my config file patch though.
>>
>> So, any comments on that patch?  Any requirements on a format?
>>
>
> 1.  Any option should be settable either in the config file or command 
> line.  In other words, the user should not be forced to use a config 
> file.  This is useful for management programs who keep all options in 
> an internal database, and for users who can experiment via a ^P edit 
> edit edit <enter>.
>
> 2. The %(blah)s syntax is a bit ugly.  It's one of the few things in 
> python I dislike.  I'd prefer ${blah} and ${blah:modifier}.
>
> 3. It would be nice to be able to embed a config file in a qcow3 
> format so that one can ship an image with some default options in one 
> file.
>
No. 3 would be an outstanding feature to have.  I think that *.vmx and 
*.vmdk is the stupidest thing ever for a commercial company like that 
trying to be portable.

-Joseph

Re: [Qemu-devel] QEMU/pc and scsi disks

[Anthony Liguori]

Joe Batt wrote:
> I disagree.  /bin/sh makes a very flexible config file format that I 
> use.  I use it on win32, Linux and Mac OS X.

The problem with only taking command line arguments is that the number 
and size of command line arguments are severely limited on certain 
platforms.  This is why almost every sufficiently aged/portable program 
supports either a config file or a method of taking command line options 
via a file.  The later is really just a particular format of a config file.

If you care about scripting QEMU, then just do something like:

qemu -config - <<EOF
hda=${myhda}
hdb=${myhdb}
EOF

Regards,

Anthony Liguori

> I would prefer that you write another cross platform shell, than 
> another config file.  At least that way I could use the same config 
> tool for more than one application.
>
> Everytime this comes up, do I have to disagree again, so that my voice 
> is not lost?
>
> Any yes, adding features that I do not use increases the complexity 
> and decreases the stability of the features I do use, so it would 
> effect me.  I have the same feeling about embedding VNC 
> authentication, the samba server, etc.
>
> Joe
>
> On Mar 2, 2007, at 11:24 AM, Anthony Liguori wrote:
>
>> Paul Brook wrote:
>>>>>> There's also no reason to limit to 7 disks, and we should support 
>>>>>> scsi
>>>>>> cdroms.
>>>>>>
>>>>> The reason for 7 is the number of available id on the scsi bus.
>>>>>
>>>> For wide scsi it is 15.
>>>>
>>>
>>> I wouldn't bet on wide scsi working.
>>> For PCI based systems you can add more host adapters to get more 
>>> devices. I haven't actually tested this, but it should work.
>>>
>>
>> I think most people agree that we need a config file.  I haven't seen 
>> any comments on my config file patch though.
>>
>> So, any comments on that patch?  Any requirements on a format?
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Paul
>>>
>>>
>>> _______________________________________________
>>> Qemu-devel mailing list
>>> Qemu-devel@nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>

Re: [Qemu-devel] QEMU/pc and scsi disks

[Thiemo Seufer]

Anthony Liguori wrote:
> Joe Batt wrote:
> >I disagree.  /bin/sh makes a very flexible config file format that I 
> >use.  I use it on win32, Linux and Mac OS X.
> 
> The problem with only taking command line arguments is that the number 
> and size of command line arguments are severely limited on certain 
> platforms.  This is why almost every sufficiently aged/portable program 
> supports either a config file or a method of taking command line options 
> via a file.  The later is really just a particular format of a config file.

FWIW, if somebody comes up with a patch for the latter method without
duplicating the option parser I'll consider applying it.


Thiemo