Re: [Qemu-devel] [PATCH] sdhci: Make device "sdhci-pci" unavailable with -device again

[Paolo Bonzini]

On 04/12/2015 15:59, Markus Armbruster wrote:
> My comment makes two claims: "wrong" and "dangerous".
> 
> First "dangerous".  You're making a non-local argument why it's not
> actually broken, and you might be right.  If you are, it's just fragile,
> not broken.  We could debate whether to call it dangerous or fragile,
> but I don't really care.  If you'd prefer to call it fragile, let's
> update the comment and the commit message.

Indeed I didn't claim it wasn't dangerous. :)  Still, that doesn't
justify disabling device-add.

> Now "wrong".  The qdev property belongs to the SD card (the thing we're
> initializing here), not the SD controller sdhci-pci.  Unfortunately, the
> SD card still hasn't been qdevified.  But if we permit tacking the
> property to the controller now, we're stuck with having it there
> forever.  No harm if the SD card never becomes an object in its own
> right.  But if it does, it'll end up in the same unhappy place as
> usb-storage, where we hackishly jump through hoops to somehow transfer
> the backend from the controller to the SCSI device.  This has caused so
> much trouble that we replaced the whole thing by usb-bot.  I'm not keen
> on repeating the experience.

That's a different kind of wrong, unrelated to blk_attach_dev.

I cannot say that it will never happen, and I'm not keen on having
another usb-storage.  That said, we have another example of automagic
property setting on children, which is virtio-blk-pci.  That one works
well, and I wonder whether lessons taught by virtio-blk-pci could be
applied to cleanup usb-storage.

But perfect is the enemy of good.  sdhci-pci is a useful device for
testing, and I don't see the point of disabling it with no qdevification
in sight for the SD card.

FWIW, I don't think the SD card will be qdevified because it doesn't
need a bus.  A host controller controls exactly one SD card, the SSI
bridge is also for exactly one SD card, etc.  So there's not much to
gain from qdevification of the card itself.  There would be a gain from
qdevification of the OMAP and StrongARM controllers (i.e. drive_get_next
is moved to the board, the problematic blk_attach_dev can disappear, etc.).

Paolo