linux-kernel - Re: [PATCH RFC -next 01/26] md/md-bitmap: introduce struct bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87eb8b55-53af-e47c-8931-044a9ab77086@huaweicloud.com>
Date: Tue, 13 Aug 2024 15:25:13 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>,
 Yu Kuai <yukuai1@...weicloud.com>
Cc: song@...nel.org, linux-kernel@...r.kernel.org,
 linux-raid@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
 "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH RFC -next 01/26] md/md-bitmap: introduce struct
 bitmap_operations

Hi,

在 2024/08/13 14:58, Mariusz Tkaczyk 写道:
> On Sat, 10 Aug 2024 10:08:29 +0800
> Yu Kuai <yukuai1@...weicloud.com> wrote:
> 
>> From: Yu Kuai <yukuai3@...wei.com>
>>
>> The structure is empty for now, and will be used in later patches to
>> merge in bitmap operations, prepare to implement a new lock free
>> bitmap in the fulture.
> 
> 
> HI Kuai,
> 
> typo: future
> 
> I think that as "later" you meant next patches in this patchset, right? If yes,
> Please you "next" instead.
> 
> At this point bringing "lock free implementation in the future" looks like
> totally unnecessary. It may happen or may not. Eventually, You can mention it in
> cover letter. What we have now is the most important.
> 
> This is just a code rework. The main goal of this (as you mentioned in second
> patch):
> 
> "So that the implementation won't be exposed, and it'll be possible
> to invent a new bitmap by replacing bitmap_operations."
> 
> but please mention that you are not going to implement second mechanism to not
> confuse reader. You need it to improve code maintainability mainly I think.
> 
> I would mention something about common "struct _ops" pattern (the special
> structure to keep related operations together) that it is going to follow now.
> 
> For me, this one can be easy merged with the patch 2, so we will got struct +
> usage in one patch.

Thanks for the review. Got it.

BTW, v2 will look totally different with v1. You can leave v1 for now. :)

Kuai

> 
> Anyway, LGTM.
> 
> Thanks,
> Mariusz
> 
> .
>