[Qemu-devel] [PATCH 0/3] Drop default SD card creation
As suggested in the recent discussion on Marcks' 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 This then allows us to drop the QEMUMachine no_sdcard flag and the vl.c code which creates a dummy IF_SD drive. Not intended for 1.2, obviously. Peter Maydell (3): omap: Get BlockDriverState* in mmc controller init, not board init pxa2xx: Get BlockDriverState* in mmc controller init, not board init Drop default SD card creation hw/boards.h |3 +-- hw/omap.h|3 +-- hw/omap1.c |8 +--- hw/omap2.c |8 +--- hw/omap_mmc.c| 12 hw/pxa.h |2 +- hw/pxa2xx.c | 16 ++-- hw/pxa2xx_mmci.c |7 +-- hw/s390-virtio.c |1 - hw/xilinx_zynq.c |1 - vl.c |7 --- 11 files changed, 20 insertions(+), 48 deletions(-) -- 1.7.9.5
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
Peter Maydell peter.mayd...@linaro.org writes: As suggested in the recent discussion on Marcks' 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 This then allows us to drop the QEMUMachine no_sdcard flag and the vl.c code which creates a dummy IF_SD drive. Not intended for 1.2, obviously. 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.
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
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? -- PMM
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
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. Don't we really want a proper QOM device for the SD card, with hotplug support. Paul
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
Peter Maydell peter.mayd...@linaro.org 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 figure you need a variant of drive_get(type, bus, unit) that creates and returns a default drive instead of null when 1. the user didn't suppress default drives with -nodefaults, and 2. (type, index) are (IF_FLOPPY, 0), (use_scsi ? IF_SCSI : IF_IDE, 2), or (IF_SD, 0), where index satisfies drive_index_to_bus_id(type, index) == bus and drive_index_to_unit_id(type, index) == unit. Happy coding :) PS: I hate drive_get_next(), because it makes which device model gets which drive depend on initialization order.
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
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?
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
On 16 August 2012 16:17, Markus Armbruster arm...@redhat.com wrote: Paul Brook p...@codesourcery.com writes: 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) This seems to be trying to draw a distinction that I don't understand. The SD card *is* the media, it's the physical object you stuff in and out of the slot on the side of your device. I guess that that means that change SD card should ideally be modelled as destroy the sd.c device object and create a new one and reconnect it to the controller but we don't really model things quite in the right way to permit that, so we fake it up at the moment by allowing the underlying BDS to change its idea of media. This works except that if the initial state is no card present we have a NULL BDS rather than one which is non-NULL but has no media at the moment. (I think Paul is suggesting that we should fix our model to move closer to this idea rather than faking things...) -- PMM
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
Peter Maydell peter.mayd...@linaro.org writes: On 16 August 2012 16:17, Markus Armbruster arm...@redhat.com wrote: Paul Brook p...@codesourcery.com writes: 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) This seems to be trying to draw a distinction that I don't understand. The SD card *is* the media, it's the physical object you stuff in and out of the slot on the side of your device. I guess that that means that change SD card should ideally be modelled as destroy the sd.c device object and create a new one and reconnect it to the controller but we don't really model things quite in the right way to permit that, so we fake it up at the moment by allowing the underlying BDS to change its idea of media. This works except that if the initial state is no card present we have a NULL BDS rather than one which is non-NULL but has no media at the moment. (I think Paul is suggesting that we should fix our model to move closer to this idea rather than faking things...) I figure there are two ways to model this, and both can work. One way is to treat the SD card as a hot-pluggable device. A card reader device model provides a connector for the SD card device model. The SD card device model is backed by a block backend, with non-removable medium. Card change is device hot plug. If the physical board doesn't let you change the card while the machine runs, and you want to model that faithfully, disable hot plug on that connector. Note that we could model floppies and CD-ROMs that way, too. Another way is to treat the SD card as media. This is possible because the guest can talk to the card only through the card reader. Card change is block backend media change. This is how we currently do block device models. The first way models the SD card as TYPE_DEVICE, the second as TYPE_MEDIUM. Except TYPE_MEDIUM doesn't exist, but after block layer QOMification, it could.
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
On 16 August 2012 16:17, Markus Armbruster arm...@redhat.com wrote: Paul Brook p...@codesourcery.com writes: 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) This seems to be trying to draw a distinction that I don't understand. The SD card *is* the media, it's the physical object you stuff in and out of the slot on the side of your device. It's the difference between not present and present but empty. In the case of an SD card the media (i.e. flash) is generally not seperable from the SD device - I don't remember if the SD spec even supports removable media. The same is true for most hard disks - the disk platters are an integral part of the drive. In these cases the present but empty state does not exist. c.f. cdrom drives where the concept of an empty device is clearly very different to an absent device. I guess that that means that change SD card should ideally be modelled as destroy the sd.c device object and create a new one and reconnect it to the controller but we don't really model things quite in the right way to permit that, so we fake it up at the moment by allowing the underlying BDS to change its idea of media. This works except that if the initial state is no card present we have a NULL BDS rather than one which is non-NULL but has no media at the moment. (I think Paul is suggesting that we should fix our model to move closer to this idea rather than faking things...) I think we have two options: A) Model the SD slot and card explicitly as separate objects. Effectively the same way we have a scsi bus with scsi drives connected to it. Cards can be hotplugged. A card has a block device that is not optional, and not removable. I don't know how well our UI handles this. It may well require user-visible changes. B) Continue to effectively model just the SD slot, with the card being implicit. The slot should always create/find a [removable] block device. An empty block device is modelled as an absent card. A slot without a block device is IMO a bug. This can create awkwardness because there's no good way to expose card specific properties (we don't curently implement any interesting ones). These should really be per-card, i.e. may change when you change the contents. However the only thing we have to attach them to is the long-lived slot object. e.g. in some cases data may be either an SD or an SDHC card. We currently make a guess. The only place to attach a user override is the SD slot, and that must be determined at machine creation, not when you associate data with the block device. Paul
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
One way is to treat the SD card as a hot-pluggable device. A card reader device model provides a connector for the SD card device model. The SD card device model is backed by a block backend, with non-removable medium. Card change is device hot plug. ... Note that we could model floppies and CD-ROMs that way, too. That's a good point. e.g. for a cdrom I'm pretty sure there's a bit somewhere that tells you whether it's a pressed cd or a cd-r. Attaching this information to a cdrom-disk device (hotplugged into a cdrom-drive) seems to make sense. Paul
