Re: [Qemu-devel] [PATCH v2 for-1.2 00/27] Suppress unused default drives

[Anthony Liguori <anthony@codemonkey.ws>]

Markus Armbruster <armbru@redhat.com> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On 15 August 2012 20:25, Alexander Graf <agraf@suse.de> wrote:
>>>> On 15.08.2012, at 21:17, Markus Armbruster wrote:
>>>>
>>>>> We create a number of default drives for machines to use: floppy,
>>>>> CD-ROM, SD card.  Machines can suppress the ones they don't use, but
>>>>> few do.  Fix that.
>>>
>>>>> v2:
>>>>>  Make default drives opt-in instead of opt-out for boards (Andreas)
>>>>>  Cover new target unicore32
>>>>>  Bonus fix for unicore32 -M puv3 without -kernel
>>>>>  Cover mpc8544ds, pseries (missed in v1)
>>>>
>>>> Nack from my POV. Too late for 1.2. Better get this in early for 1.3.
>
> What's the risk?
>
> For the record, I tested every single machine to make sure it still gets
> default drives for any drive it uses.
>
>> No, it's not too late for 1.2.
>>
>> The release process is pretty clear.  Major features needed to be posted
>> before August 1st.  The late to get non-bug fixes in is today.
>>
>> This is not a major feature but more importantly, has gone through a few
>> revisions and has gotten positive review comments.
>>
>> So let's not just go around declaring things as being "too late".  If
>> something needs more review or hasn't gotten adequate review, it's
>> perfectly acceptable to point that out.  But please don't just Nack and
>> say it's too late.
>>
>>> Agree. I also think we should follow up Paul Brook's suggestion
>>> that we don't need to have any kind of "default sd card" flag
>>> at all. Floppy is weird because we don't properly separate out
>>> the drive and the controller, right? Not sure about cdrom...
>>
>> This is a valid critique and suggests that more review is needed.
>> Given that, I won't pick this up today.  But let's not throw around
>> Nacks without justification.
>
> Paul's idea is worth pursuing.  But I don't think we should reject a
> improvement we can have now just we can imagine an even nicer
> improvement we may have some day.  Taking the former now doesn't make
> the latter any harder.

If doing it a different way means touching 50 files again, then it's
best not to rush into that.  There is something to be said to for
avoiding unnecessary churn.

Regards,

Anthony Liguori