Paul Brook <p...@codesourcery.com> writes: >> On 16 August 2012 15:11, Markus Armbruster <arm...@redhat.com> wrote: >> > Peter Maydell <peter.mayd...@linaro.org> writes: >> >> As suggested in the recent discussion on Markus' patchset to suppress >> >> unused default drives, this patchset cleans up the omap and pxa2xx >> >> >> >> SD card controllers to behave like the other controllers: >> >> * the init function looks for the next IF_SD drive >> >> * if there isn't one, we start up as a controller with no card >> >> >> >> present >> > >> > Isn't this an incompatible change? Before, you get an SD card reader >> > backed by an empty BDS default. You can load/unload cards in the >> > monitor. After, you get an SD card reader that isn't backed by a BDS by >> > default. Device models prepared for that can treat it as permanently >> > empty. >> >> Hmm, yes, but most of our SD controllers already act that way. >> We should probably fix them all... >> >> So what's the block layer equivalent of drive_get_next() that always >> returns us something we can get a bdrv from? > > I think this may be the wrong way to fix this. SD cards aren't really have > removable media. In the same way that a SCSI HDD are generally not removable > media - you hotplug the whole drive.
If an SD card device doesn't support media change, then the device model should: 1. Insist on non-null, non-empty BDS on initialization (this ensures we got media) 2. Not implement BlockDevOps method change_media_cb() (this ensures we keep it). > Don't we really want a proper QOM device for the SD card, with hotplug > support. Don't we really want that for any device model?
