From: Max Reitz <mreitz@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org,
stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing
Date: Mon, 03 Nov 2014 09:44:26 +0100 [thread overview]
Message-ID: <5457406A.9090605@redhat.com> (raw)
In-Reply-To: <87egtpzp5m.fsf@blackfin.pond.sub.org>
On 2014-10-30 at 14:02, Markus Armbruster wrote:
> Max Reitz <mreitz@redhat.com> writes:
>
>> So I guess it's my turn to give yet another opinion (or just something
>> in between of what has been already said).
>>
>> First, I'm fine with this patch, or at least the idea as there were
>> yet some quirks.
> Yes, the patch has (fixable) issues. It's really just a sketch that
> happens to work in common cases :)
>
>> But I oppose turning the warning into an error eventually. I want to
>> be able to use -hda $filename and it should work. As Kevin said, a
>> warning alone will not help a lot, though. I don't know about that, I
>> think it should work. This warning should only appear when you're
>> using qemu directly because management tools should already use -drive
>> with format= or driver=; and if you're using qemu directly you should
>> be watching stderr.
>>
>> The only way I'd be fine with turning this into an error would be to
>> make an exception for -hda and the like. There were already plans of
>> introducing pseudo block drivers for format and protocol probing; if
>> we do that we can use those block drivers for -hda. We should still
>> emit the warning, but in my opinion it should never be an error with
>> -hda, -cdrom etc.. For me, this is not about backwards compatibility
>> but because I'm using -hda myself.
> Examples of usage that is just fine (no warning):
>
> * -hda test.qcow2
>
> Fine as long as test.qcow2 is really qcow2 (as it should!), and
> either specifies a backing format (as it arguably should), or the
> backing file name is sane.
>
> * -hda disk.img
>
> Fine as long as disk.img is really a disk image (as it should).
>
> * -hda /dev/mapper/vg0-virtdisk
>
> Fine as long as the logical volume is raw. Not actually implemented
> in my patch, but it's easy enough to do.
>
> Can you give me a few examples from your usage that triggers the
> warning?
You're right, I mistook making it an error if extension and probed
format do not match for disabling probing completely. In that case I'm
withdrawing my objection, though I still don't object Kevin's proposal
either.
Max
next prev parent reply other threads:[~2014-11-03 8:44 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 16:03 [Qemu-devel] [PATCH RFC 0/2] block: Warn on insecure format probing Markus Armbruster
2014-10-28 16:03 ` [Qemu-devel] [PATCH RFC 1/2] block: Factor bdrv_probe_all() out of find_image_format() Markus Armbruster
2014-10-28 16:34 ` Eric Blake
2014-10-28 16:41 ` Jeff Cody
2014-10-29 15:22 ` Stefan Hajnoczi
2014-10-28 16:03 ` [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing Markus Armbruster
2014-10-28 17:02 ` Eric Blake
2014-10-28 18:29 ` Jeff Cody
2014-10-28 18:56 ` Eric Blake
2014-10-28 19:42 ` Jeff Cody
2014-10-29 7:36 ` Markus Armbruster
2014-10-29 8:25 ` Max Reitz
2014-10-29 7:22 ` Markus Armbruster
2014-10-30 13:58 ` Jeff Cody
2014-11-03 8:07 ` Markus Armbruster
2014-10-29 7:03 ` Markus Armbruster
2014-10-28 18:33 ` Jeff Cody
2014-10-29 6:37 ` Markus Armbruster
2014-10-30 13:52 ` Jeff Cody
2014-11-03 8:11 ` Markus Armbruster
2014-10-29 1:16 ` Fam Zheng
2014-10-29 6:32 ` Markus Armbruster
2014-10-29 10:12 ` Kevin Wolf
2014-10-29 13:54 ` Markus Armbruster
2014-10-29 15:34 ` Stefan Hajnoczi
2014-10-30 9:07 ` Markus Armbruster
2014-10-30 9:24 ` Stefan Hajnoczi
2014-10-30 12:19 ` Markus Armbruster
2014-10-30 9:30 ` Kevin Wolf
2014-10-30 12:49 ` Markus Armbruster
2014-10-31 11:19 ` Stefan Hajnoczi
2014-10-31 22:45 ` Eric Blake
2014-11-03 8:15 ` Markus Armbruster
2014-11-03 11:13 ` Kevin Wolf
2014-11-04 9:36 ` Markus Armbruster
2014-11-04 10:32 ` Kevin Wolf
2014-11-05 7:58 ` Markus Armbruster
2014-11-03 11:00 ` Kevin Wolf
2014-11-04 9:39 ` Markus Armbruster
2014-11-04 16:09 ` Jeff Cody
2014-11-05 8:05 ` Markus Armbruster
2014-11-05 8:09 ` Max Reitz
2014-10-30 9:08 ` Max Reitz
2014-10-30 9:27 ` Stefan Hajnoczi
2014-10-30 9:36 ` Kevin Wolf
2014-10-31 11:24 ` Stefan Hajnoczi
2014-10-31 11:56 ` Kevin Wolf
2014-11-03 8:54 ` Markus Armbruster
2014-11-03 9:11 ` Max Reitz
2014-11-04 9:34 ` Markus Armbruster
2014-11-03 10:25 ` Kevin Wolf
2014-11-03 15:05 ` Stefan Hajnoczi
2014-11-03 15:13 ` Max Reitz
2014-11-04 9:42 ` Markus Armbruster
2014-11-04 10:11 ` Kevin Wolf
2014-11-04 15:25 ` Stefan Hajnoczi
2014-11-04 15:37 ` Kevin Wolf
2014-11-05 8:39 ` Markus Armbruster
2014-11-05 10:18 ` Eric Blake
2014-10-30 13:02 ` Markus Armbruster
2014-11-03 8:44 ` Max Reitz [this message]
2014-10-30 20:45 ` Richard W.M. Jones
2014-11-03 8:18 ` Markus Armbruster
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=5457406A.9090605@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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).