From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5sZR-00027v-To for qemu-devel@nongnu.org; Mon, 07 Dec 2015 04:59:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5sZO-000355-O7 for qemu-devel@nongnu.org; Mon, 07 Dec 2015 04:59:01 -0500 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:33967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5sZO-000351-JW for qemu-devel@nongnu.org; Mon, 07 Dec 2015 04:58:58 -0500 Received: by wmvv187 with SMTP id v187so158091085wmv.1 for ; Mon, 07 Dec 2015 01:58:58 -0800 (PST) Sender: Paolo Bonzini References: <87bnde2nf2.fsf@blackfin.pond.sub.org> <8737yq181q.fsf@blackfin.pond.sub.org> <8737vizn4c.fsf@blackfin.pond.sub.org> <5661C289.9000506@redhat.com> <20151204192400.GD28805@morn.lan> <20151207061114.GA29495@morn.lan> <87bna27ic5.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <56655861.3000203@redhat.com> Date: Mon, 7 Dec 2015 10:58:57 +0100 MIME-Version: 1.0 In-Reply-To: <87bna27ic5.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Kevin O'Connor Cc: Peter Maydell , Peter Crosthwaite , QEMU Developers , Stefan Hajnoczi , Patch Tracking 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. I don't see any real difference between sdhci-pci and pci-serial. Paolo