qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: Kevin Wolf <kwolf@redhat.com>, Eric Blake <eblake@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu block <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Slutz, Donald Christopher" <dslutz@verizon.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] vl.c: Since the help says that 'disk_image' is a raw hard disk image, pass format=raw
Date: Thu, 30 Apr 2015 19:28:34 -0400	[thread overview]
Message-ID: <5542BAA2.3060802@Verizon.com> (raw)
In-Reply-To: <20150430201534.GB3545@noname.redhat.com>

On 04/30/15 16:15, Kevin Wolf wrote:
> Am 30.04.2015 um 21:15 hat Eric Blake geschrieben:
>> [adding qemu-block]
>> 
>> On 04/30/2015 12:23 PM, Don Slutz wrote:
>>> ~/qemu/out/master/x86_64-softmmu/qemu-system-x86_64 -h | head 
>>> QEMU emulator version 2.3.50, Copyright (c) 2003-2008 Fabrice
>>> Bellard usage: qemu-system-x86_64 [options] [disk_image]
>>> 
>>> 'disk_image' is a raw hard disk image for IDE hard disk 0
>>> 
>>> Standard options: ...
>>> 
>>> Signed-off-by: Don Slutz <dslutz@verizon.com> --- vl.c | 3 ++- 
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>> 
>> Without this, qemu will try to probe formats.  It is  arguably is
>> more convenient when using the shorthand of supplying a disk
>> image to let qemu pick the format; but as the --help text says
>> the image is raw, it's better to be explicit and avoid probing.
>> Besides, we can always use longhand to specify actual format
>> and/or probing if we don't like the shorthand.
> 
> I don't think you can take an outdated help text as a justification
> for breaking backwards compatibility.
> 

Is this a hard no, soft no, or TBD?

The following is what prompted this:

WARNING: Image format was not specified for '/dev/etherd/e500.1' and
probing guessed raw.
         Automatically detecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.


which I would say also breaks backwards compatibility.  However I do
agree that this is the "right" change to have done.  However there
currently is no way to specify that the 'disk_image' is raw.

Also the old options (-hda, -hdb, -hdc, and -hdd) all have similar issues.

So do you want a more complex patch that allows the format to be
specified?

Only for 'disk_image'?

Include -hd* ?

Change the help message also?

   -Don Slutz

> Kevin
> 
>>> 
>>> diff --git a/vl.c b/vl.c index 74c2681..93e674f 100644 ---
>>> a/vl.c +++ b/vl.c @@ -1084,6 +1084,7 @@ static int
>>> cleanup_add_fd(QemuOpts *opts, void *opaque) /* QEMU Block
>>> devices */
>>> 
>>> #define HD_OPTS "media=disk" +#define HD_OPTS_RAW
>>> "media=disk,format=raw" #define CDROM_OPTS "media=cdrom" 
>>> #define FD_OPTS "" #define PFLASH_OPTS "" @@ -2862,7 +2863,7 @@
>>> int main(int argc, char **argv, char **envp) if (optind >=
>>> argc) break; if (argv[optind][0] != '-') { -
>>> hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS); +
>>> hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++],
>>> HD_OPTS_RAW); } else { const QEMUOption *popt;
>>> 
>>> 
>> 
>> -- Eric Blake   eblake redhat com    +1-919-301-3266 Libvirt
>> virtualization library http://libvirt.org
>> 
> 
> 

  reply	other threads:[~2015-04-30 23:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 18:23 [Qemu-devel] [PATCH 1/1] vl.c: Since the help says that 'disk_image' is a raw hard disk image, pass format=raw Don Slutz
2015-04-30 19:15 ` Eric Blake
2015-04-30 19:17   ` Eric Blake
2015-04-30 20:15   ` Kevin Wolf
2015-04-30 23:28     ` Don Slutz [this message]
2015-05-04 11:08       ` Kevin Wolf
2015-05-04 13:39         ` Markus Armbruster
2015-05-04 14:17           ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5542BAA2.3060802@Verizon.com \
    --to=dslutz@verizon.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).