Skip to content
  • Kevin Wolf's avatar
    004e95df
    job: Convert block_job_cancel_async() to Job · 004e95df
    Kevin Wolf authored
    
    
    block_job_cancel_async() did two things that were still block job
    specific:
    
    * Setting job->force. This field makes sense on the Job level, so we can
      just move it. While at it, rename it to job->force_cancel to make its
      purpose more obvious.
    
    * Resetting the I/O status. This can't be moved because generic Jobs
      don't have an I/O status. What the function really implements is a
      user resume, except without entering the coroutine. Consequently, it
      makes sense to call the .user_resume driver callback here which
      already resets the I/O status.
    
      The old block_job_cancel_async() has two separate if statements that
      check job->iostatus != BLOCK_DEVICE_IO_STATUS_OK and job->user_paused.
      However, the former condition always implies the latter (as is
      asserted in block_job_iostatus_reset()), so changing the explicit call
      of block_job_iostatus_reset() on the former condition with the
      .user_resume callback on the latter condition is equivalent and
      doesn't need to access any BlockJob specific state.
    
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    004e95df
    job: Convert block_job_cancel_async() to Job
    Kevin Wolf authored
    
    
    block_job_cancel_async() did two things that were still block job
    specific:
    
    * Setting job->force. This field makes sense on the Job level, so we can
      just move it. While at it, rename it to job->force_cancel to make its
      purpose more obvious.
    
    * Resetting the I/O status. This can't be moved because generic Jobs
      don't have an I/O status. What the function really implements is a
      user resume, except without entering the coroutine. Consequently, it
      makes sense to call the .user_resume driver callback here which
      already resets the I/O status.
    
      The old block_job_cancel_async() has two separate if statements that
      check job->iostatus != BLOCK_DEVICE_IO_STATUS_OK and job->user_paused.
      However, the former condition always implies the latter (as is
      asserted in block_job_iostatus_reset()), so changing the explicit call
      of block_job_iostatus_reset() on the former condition with the
      .user_resume callback on the latter condition is equivalent and
      doesn't need to access any BlockJob specific state.
    
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
Loading