On 07/16/09 16:10, Anthony Liguori wrote:
Why "-drive.ID.NAME VALUE", "-net.ID.NAME VALUE" and so forth, i.e. one
option per object with parameters? Assuming the ID name space is flat,
a single option suffices. What about "-set ID.NAME=VALUE"?
Looks attractive on the surface. Feels really diffi
On 07/16/09 15:43, Markus Armbruster wrote:
Why "-drive.ID.NAME VALUE", "-net.ID.NAME VALUE" and so forth, i.e. one
option per object with parameters? Assuming the ID name space is flat,
a single option suffices. What about "-set ID.NAME=VALUE"?
Hmm, I think we will have multiple namespaces.
Markus Armbruster wrote:
Anthony Liguori writes:
Blue Swirl wrote:
Then how about something like:
-drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
-drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
-drive name=sdb,if=scsi,unit=1,fnarg -fnarg b
Anthony Liguori writes:
> Blue Swirl wrote:
>> Then how about something like:
>> -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
>> -drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
>> -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
>>
>
> The ex
On (Wed) Jul 15 2009 [10:40:37], Anthony Liguori wrote:
> Blue Swirl wrote:
>> Then how about something like:
>> -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
>> -drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
>> -drive name=sdb,if=scsi,unit=1,fnarg -
Ram Pai schrieb:
> On Wed, 2009-07-15 at 18:04 +0300, Blue Swirl wrote:
>> On 7/15/09, Ram Pai wrote:
>>> Problem: It is impossible to feed filenames with the character colon because
>>> qemu interprets such names as a protocol. For example filename scsi:0, is
>>> interpreted as a protocol by na
On Wed, 2009-07-15 at 18:04 +0300, Blue Swirl wrote:
> On 7/15/09, Ram Pai wrote:
> > Problem: It is impossible to feed filenames with the character colon because
> > qemu interprets such names as a protocol. For example filename scsi:0, is
> > interpreted as a protocol by name "scsi".
>
> > -
On Wed, 2009-07-15 at 22:04 +0100, Jamie Lokier wrote:
> Ram Pai wrote:
> > I have successfully verified qcow2 files. But then I may not be trying
> > out the exact thing that you are talking about. Can you give me a test
> > case that I can verify.
>
> Commands tried with qemu-0.10.0-1ubuntu1:
>
Ram Pai wrote:
> I have successfully verified qcow2 files. But then I may not be trying
> out the exact thing that you are talking about. Can you give me a test
> case that I can verify.
Commands tried with qemu-0.10.0-1ubuntu1:
$ mkdir unlikely_subdir
$ cd unlikely_subdir
$ qemu-img create -f q
On Wed, 2009-07-15 at 19:20 +0100, Jamie Lokier wrote:
> Ram Pai wrote:
> > I have verified with relative paths and it works.
> >
> > After analyzing the code, i came to the conclusion that call to
> > realpath() adds no real value.
> >
> > The logic in bdrv_open2() is something like this
> >
Ram Pai wrote:
> I have verified with relative paths and it works.
>
> After analyzing the code, i came to the conclusion that call to
> realpath() adds no real value.
>
> The logic in bdrv_open2() is something like this
>
> bdrv_open2()
> {
>if (snapshot) {
> backup = realpath(fi
On Wed, Jul 15, 2009 at 10:40:37AM -0500, Anthony Liguori wrote:
> Blue Swirl wrote:
>> Then how about something like:
>> -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
>> -drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
>> -drive name=sdb,if=scsi,unit=
On Wed, 2009-07-15 at 11:30 +0200, Jan Kiszka wrote:
> Ram Pai wrote:
> > Problem: It is impossible to feed filenames with the character colon because
> > qemu interprets such names as a protocol. For example filename scsi:0, is
> > interpreted as a protocol by name "scsi".
> >
> > This patch allo
Anthony Liguori schrieb:
> Blue Swirl wrote:
>> Then how about something like:
>> -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
>> -drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
>> -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
>>
>
> The ex
> Instead of using '-drive if=none' we could use some other syntax where
> the filename can be passed as separate argument. Can switches have two
> arguments? If so, maybe this:
>
>-hostdrive $file $options
This only works for a single mandatory argument that needs to contain awkward
charac
On 07/15/09 17:14, Anthony Liguori wrote:
Blue Swirl wrote:
I bet this won't compile on win32.
Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda "filename with
f
On Wednesday 15 July 2009, Anthony Liguori wrote:
> Blue Swirl wrote:
> > I bet this won't compile on win32.
> >
> > Instead of this (IMHO doomed) escape approach, maybe the filename
> > parameter could be specified as the next argument, for example:
> > -hda format=qcow2,blah,blah,filename_is_next
Blue Swirl wrote:
Then how about something like:
-drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
-drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
-drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
The explicit ordering part seems clunky to me. H
Kevin Wolf wrote:
Anthony Liguori schrieb:
Blue Swirl wrote:
I bet this won't compile on win32.
Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda "filen
Anthony Liguori schrieb:
> Blue Swirl wrote:
>> I bet this won't compile on win32.
>>
>> Instead of this (IMHO doomed) escape approach, maybe the filename
>> parameter could be specified as the next argument, for example:
>> -hda format=qcow2,blah,blah,filename_is_next_arg -hda "filename with
>> fu
On 7/15/09, Anthony Liguori wrote:
> Blue Swirl wrote:
>
> > I bet this won't compile on win32.
> >
> > Instead of this (IMHO doomed) escape approach, maybe the filename
> > parameter could be specified as the next argument, for example:
> > -hda format=qcow2,blah,blah,filename_is_next_arg -hda
>
Blue Swirl wrote:
I bet this won't compile on win32.
Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda "filename with
funky characters like ',' ':' & '!'"
-d
On 7/15/09, Ram Pai wrote:
> Problem: It is impossible to feed filenames with the character colon because
> qemu interprets such names as a protocol. For example filename scsi:0, is
> interpreted as a protocol by name "scsi".
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> +static int
Ram Pai wrote:
> Problem: It is impossible to feed filenames with the character colon because
> qemu interprets such names as a protocol. For example filename scsi:0, is
> interpreted as a protocol by name "scsi".
>
> This patch allows user to espace colon characters. For example the above
> filen
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name "scsi".
This patch allows user to espace colon characters. For example the above
filename can now be expressed ei
25 matches
Mail list logo
