qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify "drive is suitable f


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify "drive is suitable for microdrive" test
Date: Tue, 09 Aug 2011 14:36:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 09.08.2011 13:56, schrieb Markus Armbruster:
>> bdrv_is_locked() is about the frontend's media lock.  To make this more
>> obvious, my PATCH 29/55 replaces it by bdrv_dev_is_medium_locked().  It
>> does *not* query the backend's lock (which may not even exist!) set by
>> bdrv_set_locked().
>
> This sounds wrong (the behaviour, not your analysis). Do you plan to
> remove bdrv_dev_is_medium_locked() as well? It is used by IDE and
> scsi-disk (easy to replace) and in eject_device() in blockdev.c. Maybe
> the 'eject' monitor command should be handled by another callback into
> the device.

Just two users remain after my series:

* bdrv_info()

  It wants to show the frontend's lock state, and uses
  bdrv_dev_is_medium_locked() to get it from the frontend.

* eject_device()

  It needs to fail if the frontend has its medium locked.  It uses
  bdrv_dev_is_medium_locked() to get the lock state from the frontend.
  Pseudo code (-f glossed over for simplicity):

      unless frontend has removable media
              fail
      if frontend medium is not already open
         and frontend medium is locked
              fail
      drop the block driver

  I considered replacing this with "ask the frontend to eject", and then
  let the frontend decide whether to order the backend to drop the block
  driver.  I decided against it, since I need
  bdrv_dev_is_medium_locked() anyway for bdrv_info().  Besides, the
  series is long enough already.



reply via email to

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