Re: [PATCH v2] samples/damon/mtier: use damon_addr_range consistently

[Enze Li <lienze@kylinos.cn>]

Hi SJ,

On 7/21/26 9:28 AM, SJ Park wrote:
> Hello Enze,
> 
> On Mon, 20 Jul 2026 21:06:42 +0800 Enze Li <lienze@kylinos.cn> wrote:
> 
>> The DAMON provides struct damon_addr_range for unified address range
>> management.  However, the mtier sample still defines a local struct
>> region_range and mixes its usage with struct damon_addr_range in
>> damon_sample_mtier_build_ctx().
> 
> damon_addr_range is for DAMON core layer address system that uses 'unsigned
> long' as the address type.  Because 'mtier' is dealing directly with physical
> address, we use a dedicated struct for that purpose.  On 32bit systems having
> more than 4 GiB memory, this may be necessary.
> 
> 'mtier' doesn't really take care of the >4GiB 32bit system since it is simply
> casting the 'phys_addr_t' addresses into 'unsigned long' addresses.  But it
> might support it better in future, using the addr_unit parameter.
> 
>>
>> This patch removes the local struct region_range and changes the
>> parameter type of nid_to_phys() to struct damon_addr_range.  It also
>> gets rid of the now-redundant local variable and pass the address range
>> directly to damon_set_regions().
> 
> So, I don't think this change is required as-is.  I don't really want to add
> addr_unit support for >4GiB 32bit system, either, unless it turns out to be
> really needed.  I'd like to keep sample modules as simple as possible.  If the
> code was confusing you because it is anyway casting the types, adding a comment
> explaining the rationale might be a better change, in my opinion.

Thanks for the explanation and the feedback -- I agree that keeping
struct region_range is the right call.  Per your suggestion, I've
prepared a new patch that simply adds a comment to clarify the rationale.

Best Regards,
Enze

<...>