1. 31 5月, 2018 2 次提交
    • N
      btrfs: Factor out write portion of btrfs_get_blocks_direct · c5794e51
      Nikolay Borisov 提交于
      Now that the read side is extracted into its own function, do the same
      to the write side. This leaves btrfs_get_blocks_direct_write with the
      sole purpose of handling common locking required. Also flip the
      condition in btrfs_get_blocks_direct_write so that the write case
      comes first and we check for if (Create) rather than if (!create). This
      is purely subjective but I believe makes reading a bit more "linear".
      No functional changes.
      Signed-off-by: NNikolay Borisov <nborisov@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      c5794e51
    • N
      btrfs: Factor out read portion of btrfs_get_blocks_direct · 1c8d0175
      Nikolay Borisov 提交于
      Currently this function handles both the READ and WRITE dio cases. This
      is facilitated by a bunch of 'if' statements, a goto short-circuit
      statement and a very perverse aliasing of "!created"(READ) case
      by setting lockstart = lockend and checking for lockstart < lockend for
      detecting the write. Let's simplify this mess by extracting the
      READ-only code into a separate __btrfs_get_block_direct_read function.
      This is only the first step, the next one will be to factor out the
      write side as well. The end goal will be to have the common locking/
      unlocking code in btrfs_get_blocks_direct and then it will call either
      the read|write subvariants. No functional changes.
      Signed-off-by: NNikolay Borisov <nborisov@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      1c8d0175
  2. 30 5月, 2018 31 次提交
  3. 29 5月, 2018 7 次提交