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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> Markus Armbruster <address@hidden> writes:
>
>> Anthony Liguori <address@hidden> writes:
>>
>>> Peter Maydell <address@hidden> writes:
>>>
>>>> On 15 August 2012 20:25, Alexander Graf <address@hidden> 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.

Three cases:

1. Reject my small improvement now, take the nicer improvement later.

2. Take the small improvement now, take the nicer improvement later.
The latter has to remove 94 lines ".no_FOO = 1" it wouldn't have to in
case 1.  BFD.

3. Reject the small improvement now, nicer improvement fails to
materialize.  

I think you're exaggerating the 2's drawback and ignoring 3's.