[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] QEMU/pc and scsi disks
Date: Sun, 25 Mar 2007 12:05:41 -0500
User-agent: Thunderbird (X11/20070307)

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


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.


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

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?


Anthony Liguori


Qemu-devel mailing list

Qemu-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]