Thanks Michał for replying.
On 6/27/23 11:52 PM, Michał Mirosław wrote:
> On Tue, 27 Jun 2023 at 11:00, Muhammad Usama Anjum
> <usama.anjum@xxxxxxxxxxxxx> wrote:
>>
>> Hi Andrei and Michal,
>>
>> Lets resolve last two points. Please reply below.
>>
>> On 6/27/23 6:46 AM, Andrei Vagin wrote:
> [...]
>>> And we need to report an address where it stopped scanning.
>>> We can do that by adding zero length vector.
>> I don't want to do multiplexing the ending address in vec. Can we add
>> end_addr variable in struct pm_scan_arg to always return the ending address?
>>
>> struct pm_scan_arg {
>> ...
>> _u64 end_addr;
>> };
>
> The idea to emit a zero-length entry for the end looks nice. This has
> the disadvantage that we'd need to either reserve one entry for the
> ending marker or stop the walk after the last entry is no longer
> matching.
This is ambiguous.
>
> Another solution would be to rewrite 'start' and 'len'. The caller
> would be forced to use non-const `pm_scan_arg`, but I expect the `vec`
> pointer would normally be written anyway (unless using only a
> statically-allocated buffer).
> Also, if the 'len' is replaced with 'end' that would make the ioctl
> easily restartable (just call again if start != end).
Nice idea. But returning ending address in len seems a bit strange.
pm_scan_arg already has 11 members. Wouldn't it be okay to add one more? It
would be straight forward as well.
If nobody replies until tomorrow, I'll start returning ending address in len.
>
> Best Regards
> Michał Mirosław
--
BR,
Muhammad Usama Anjum
