On 7 December 2015 at 10:31, Markus Armbruster <arm...@redhat.com> wrote: > Paolo Bonzini <pbonz...@redhat.com> 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