Re: [Qemu-devel] [RFC v2 0/3] Q35/AHCI -cdrom/-hda desugaring

[John Snow <jsnow@redhat.com>]

On 09/19/2014 05:53 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
>
>> This is an extremely rough/quick sketch of
>> a -cdrom/-hda desugaring fix for Q35/AHCI.
>>
>> Before I spent any time on it, I wanted feedback
>> from Markus or anyone else who had concerns about
>> how this problem would get fixed.
>>
>> This is, then, rough approach #2.
>>
>> Highlights:
>> (1) Add a board property (instead of a HBA property, sigh)
>>      that defines how we should map (index, (bus,unit)).
>
> Imperfect, but it'll do for now.  The place in the boards that sets it
> should point to the HBA in a comment.
>
>> (2) Modify drive_new to accept the MachineClass instead of
>>      the default interface type. This does not affect how
>>      default drives get added, because any over-rides to
>>      the "default type" get handled in options, so while
>>      it appears we have removed the type of default drives,
>>      we have not.
>>
>> (3) Create helpers for AHCI to assist the Q35 board in
>>      populating the AHCI device with the IDE drives.
>>
>> (4) Create a helper to whine at us for oversights and
>>      help bug reporters give us more meaningful information.
>
> General approach looks good to me; I can see only coding bugs, not
> design flaws.
>

I rewrote this series and was about to send it out, but it does fail the 
bios-tables-test because this test uses this command line:

-net none -display none -machine q35,accel=tcg -drive 
file=tests/acpi-test-disk.raw,id=hd0 -device ide-hd,drive=hd0,

Notice it doesn't say if=none for the drive, so after fixing Q35, this 
actually creates a new failure in this test because we will create the 
drive (and device), then fail when trying to create the second device 
attached to the same drive.

I think this test is at fault, but I wanted to be duly diligent and ask 
the question: "Is it a big deal if I break backwards compatibility with 
broken scripts?"

-- 
—js