Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice object

[Peter Maydell]

On 7 December 2015 at 10:31, Markus Armbruster <address@hidden> wrote:
> Paolo Bonzini <address@hidden> writes:
>
>> On 07/12/2015 09:50, Markus Armbruster wrote:
>>> The device is obviously useful.  However, there is dissent on how it
>>> ought to be modelled.  The modelling is visible at the -device user
>>> interface.  By making the device available there in 2.5, we commit to
>>> the current modelling's user interface before we reach consensus on how
>>> it ought to be modelled.  Options:
>>>
>>> (1) Make device "sdhci-pci" unavailable with -device until we reach
>>>     consensus.  This is what we normally do.  Trivial patch is on list.
>>>
>>> (2) Mark the properties that belong to the card rather than the
>>>     controller as experimental until we reach consensus, by prefixing
>>>     their name with "x-".  Needs a patch.
>>>
>>> (3) Keep it available, commit to the user interface, deal with the
>>>     consequences if and when they arise.
>>>
>>> I think (1) is the most prudent, but (2) should work, too.  Having dealt
>>> with consequences of prior modelling mistakes, I dislike 3.
>>
>> There have been 10 commits in 2 years to sd.c, none of them getting a
>> step closer to qdev-ification basically.  So there's no interest, which
>> is basically explained by the fact that quite frankly SDIO is dead.
>
> There hasn't been progress towards qdevification because we've offered
> neither sticks nor carrots to the donkeys who're supposed to do the
> donkey-work.

I will QOMify sd.c for 2.6. (Most of the users are ARM boards anyway.)

>> I don't see any real difference between sdhci-pci and pci-serial.
>
> The difference is dissent vs. consensus.
>
> I don't have a strong opinion myself, but Peter C. seems to have.
>
> I suppose we could find rough consensus, but finding it under duress of
> a release isn't how we normally do it.
>
> Option (2) would make the device available for testing in 2.5 without
> breaking off the debate before consensus is reached or it becomes clear
> it cannot be reached.

I definitely would prefer us not to have to be stuck with a wrongly
modelled sd.c. So I'd prefer option (1) or option (2). Option 2
would allow people to use the device in 2.5 at least.

The release notes will also want a warning that sdhci might end
up with a migration compatibility break in 2.6. (Obviously we'd try
to avoid that but QOMifying sd.c might require it.)

thanks
-- PMM