qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH] vl: disable default cdrom when u


From: John Snow
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


On 02/19/2017 08:00 PM, Markus Armbruster wrote:
> Hervé Poussineau <address@hidden> writes:
> 
>> Hi,
>>
>> Le 09/01/2017 à 14:48, Paolo Bonzini a écrit :
>>>
>>>
>>> On 09/01/2017 13:49, Markus Armbruster wrote:
>>>> Hervé Poussineau <address@hidden> 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 <address@hidden>, cc: address@hidden
> 

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



reply via email to

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