From: John Snow <jsnow@redhat.com>
To: "Markus Armbruster" <armbru@redhat.com>,
"Hervé Poussineau" <hpoussin@reactos.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-trivial@nongnu.org, Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>,
qemu-block@nongnu.org
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] vl: disable default cdrom when using explicitely scsi-hd
Date: Mon, 20 Feb 2017 14:54:29 -0500 [thread overview]
Message-ID: <75f7111c-d7b1-e2a1-449f-52c38ef2d07f@redhat.com> (raw)
In-Reply-To: <87a89hvfpd.fsf@dusky.pond.sub.org>
On 02/19/2017 08:00 PM, Markus Armbruster wrote:
> Hervé Poussineau <hpoussin@reactos.org> writes:
>
>> Hi,
>>
>> Le 09/01/2017 à 14:48, Paolo Bonzini a écrit :
>>>
>>>
>>> On 09/01/2017 13:49, Markus Armbruster wrote:
>>>> Hervé Poussineau <hpoussin@reactos.org> writes:
>>>>
>>>>> 'ide-hd', 'ide-cd' and 'scsi-cd' devices already disable default cdrom.
>>>>> Make it the same for 'scsi-hd'.
>>>>>
>>>>> That way, we can add/replace the device on lun=2 without using -nodefaults.
>>>>
>>>> Yes, but it might upset existing usage that relies on the default
>>>> CD-ROM. In my opinion, making your needs explicit is better than
>>>> relying on defaults, but that doesn't mean we can change the defaults
>>>> unthinkingly. Definitely not qemu-trivial.
>>>>
>>>> Opinions on the change?
>>>
>>> The original rationale for the change was "ide-hd has to suppress the
>>> default CD-ROM, or else you can't put one on secondary master without
>>> -nodefaults" but the same applies for scsi-hd vs. lun=1.
>>>
>>> So I'm not sure, but I lean towards accepting the patch.
>>>
>>> Paolo
>>
>> Paolo, Markus, so what is the conclusion?
>> Accepting the patch, or refusing it?
>
> Suggest to repost with the commit message updated to mention the
> backwards incompatibility, and why you think it's okay.
> cc: John Snow <jsnow@redhat.com>, cc: qemu-block@nongnu.org
>
I don't have a lot of history with the SCSI devices, so I'd be pretty
much relying exclusively on a statement on what breaks with the change,
and why that breakage would be justified.
No strong feelings for/against right now and am likely to just defer to
Paolo, who was leaning towards accepting it.
--js
prev parent reply other threads:[~2017-02-20 19:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-31 14:34 [Qemu-trivial] [PATCH] vl: disable default cdrom when using explicitely scsi-hd Hervé Poussineau
2017-01-09 12:49 ` [Qemu-trivial] [Qemu-devel] " Markus Armbruster
2017-01-09 13:48 ` [Qemu-trivial] " Paolo Bonzini
2017-02-18 17:58 ` Hervé Poussineau
2017-02-20 1:00 ` [Qemu-trivial] [Qemu-devel] " Markus Armbruster
2017-02-20 19:54 ` John Snow [this message]
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=75f7111c-d7b1-e2a1-449f-52c38ef2d07f@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=hpoussin@reactos.org \
--cc=laurent@vivier.eu \
--cc=mjt@tls.msk.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.