[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 09/17] hw/sd/sdcard: Special case the -ENOMEDIUM error

From: Markus Armbruster
Subject: Re: [PATCH v7 09/17] hw/sd/sdcard: Special case the -ENOMEDIUM error
Date: Mon, 06 Jul 2020 07:52:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 30 Jun 2020 at 14:39, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> As we have no interest in the underlying block geometry,
>> directly call blk_getlength(). We have to care about machines
>> creating SD card with not drive attached (probably incorrect
>> API use). Simply emit a warning when such Frankenstein cards
>> of zero size are reset.
> Which machines create SD cards without a backing block device?
> I have a feeling that also the monitor "change" and "eject"
> commands can remove the backing block device from the SD card
> object.


    static const BlockDevOps sd_block_ops = {
        .change_media_cb = sd_cardchange,

This is TYPE_SD_CARD's ("sd-card").  What exactly does that device

If it's the sd-card, then the modelling is odd.  A physical SD card gets
plugged and unplugged as a whole.  This model can't.  Instead, you
change "media".  Isn't the SD card the medium?

The other device models with removable media (IDE & SCSI CD drives,
floppy drives) model the receptacle for media.  On media change, the
drive stays put, and only the medium changes, both in the physical world
and in our virtual world.

Our "sd-card" seems to be an "SD card drive".  But then I wonder what
the thing at the other end of TYPE_SD_BUS ("sd-bus") actually models.
Any ideas?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]