1. 24 9月, 2012 5 次提交
    • J
      block: Framework for reopening files safely · e971aa12
      Jeff Cody 提交于
      This is based on Supriya Kannery's bdrv_reopen() patch series.
      
      This provides a transactional method to reopen multiple
      images files safely.
      
      Image files are queue for reopen via bdrv_reopen_queue(), and the
      reopen occurs when bdrv_reopen_multiple() is called.  Changes are
      staged in bdrv_reopen_prepare() and in the equivalent driver level
      functions.  If any of the staged images fails a prepare, then all
      of the images left untouched, and the staged changes for each image
      abandoned.
      
      Block drivers are passed a reopen state structure, that contains:
          * BDS to reopen
          * flags for the reopen
          * opaque pointer for any driver-specific data that needs to be
            persistent from _prepare to _commit/_abort
          * reopen queue pointer, if the driver needs to queue additional
            BDS for a reopen
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e971aa12
    • J
      block: make bdrv_set_enable_write_cache() modify open_flags · 55b110f2
      Jeff Cody 提交于
      bdrv_set_enable_write_cache() sets the bs->enable_write_cache flag,
      but without the flag recorded in bs->open_flags, then next time
      a reopen() is performed the enable_write_cache setting may be
      inadvertently lost.
      
      This will set the flag in open_flags, so it is preserved across
      reopens.
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      55b110f2
    • J
      block: correctly set the keep_read_only flag · be028adc
      Jeff Cody 提交于
      I believe the bs->keep_read_only flag is supposed to reflect
      the initial open state of the device. If the device is initially
      opened R/O, then commit operations, or reopen operations changing
      to R/W, are prohibited.
      
      Currently, the keep_read_only flag is only accurate for the active
      layer, and its backing file. Subsequent images end up always having
      the keep_read_only flag set.
      
      For instance, what happens now:
      
      [  base  ]  kro = 1, ro = 1
          |
          v
      [ snap-1 ]  kro = 1, ro = 1
          |
          v
      [ snap-2 ]  kro = 0, ro = 1
          |
          v
      [ active ]  kro = 0, ro = 0
      
      What we want:
      
      [  base  ]  kro = 0, ro = 1
          |
          v
      [ snap-1 ]  kro = 0, ro = 1
          |
          v
      [ snap-2 ]  kro = 0, ro = 1
          |
          v
      [ active ]  kro = 0, ro = 0
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      be028adc
    • K
      blockdev: preserve readonly and snapshot states across media changes · 80dd1aae
      Kevin Shanahan 提交于
      If readonly=on is given at device creation time, the ->readonly flag
      needs to be set in the block driver state for this device so that
      readonly-ness is preserved across media changes (qmp change command).
      Similarly, to preserve the snapshot property requires ->open_flags to
      be correct.
      Signed-off-by: NKevin Shanahan <kmshanah@disenchant.net>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      80dd1aae
    • S
      w32: Add implementation of gmtime_r, localtime_r · d3e8f957
      Stefan Weil 提交于
      Those functions are missing in MinGW.
      
      Some versions of MinGW-w64 include defines for gmtime_r and localtime_r.
      Older versions of these macros are buggy (they return a pointer to a
      static variable), therefore we don't want them. Newer versions are
      similar to the code used here, but without the memset.
      
      The implementation which is used here is not strictly reentrant,
      but sufficiently good for QEMU on w32 or w64.
      Signed-off-by: NStefan Weil <sw@weilnetz.de>
      [blauwirbel@gmail.com: added comment about locking]
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      d3e8f957
  2. 23 9月, 2012 13 次提交
  3. 22 9月, 2012 22 次提交