> 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
