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

[Markus Armbruster]

Markus Armbruster <address@hidden> writes:

> 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.

PS: By "now" I mean "before this series bit-rots", not "in time for
1.2".