On 2018/03/23 18:14, Qu Wenruo wrote:
>
>
> On 2018年03月23日 16:20, Misono Tomohiro wrote:
>> The kernel code no longer has BTRFS_CRC32_SIZE and only uses
>> btrfs_csum_sizes[]. So, update the progs code as well.
>>
>> Suggested-by: Qu Wenruo <w...@suse.com>
>> Signed-off-by: Tomohiro Misono <misono.tomoh...@jp.fujitsu.com>
>> ---
>> convert/common.c | 2 +-
>> convert/main.c | 2 +-
>> ctree.h | 3 +--
>> image/main.c | 4 ++--
>> mkfs/common.c | 14 +++++++-------
>> 5 files changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/convert/common.c b/convert/common.c
>> index 3860f3b9..2b944fd8 100644
>> --- a/convert/common.c
>> +++ b/convert/common.c
>> @@ -219,7 +219,7 @@ static inline int write_temp_extent_buffer(int fd,
>> struct extent_buffer *buf,
>> {
>> int ret;
>>
>> - csum_tree_block_size(buf, BTRFS_CRC32_SIZE, 0);
>> + csum_tree_block_size(buf, btrfs_csum_sizes[BTRFS_CSUM_TYPE_CRC32], 0);
>
> I'd say the normal kernel way to do this is like this, other than using
> BTRFS_CSUM_TYPE_CRC32:
> u16 csum_size = btrfs_super_csum_size(fs_info->super_copy);
>
> Thanks,
> Qu
Thanks, but we cannot access fs_info or struct btrfs_super_block here (and
others in this diff).
Should we pass the csum type parameter as an argument? Since currently the only
supported type is crc32, I'm not sure if we should write the code so generic at
this time.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
