Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation

[Paul Brook]

> On 16 August 2012 16:17, Markus Armbruster <address@hidden> wrote:
> > Paul Brook <address@hidden> 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