Re: [PATCH v5 0/4] tools/accounting: refactor delay fields and share format_timespec()

[wang.yaxin]

>> - Convert per-field delay members in struct task_info to an array indexed
>>   by enum delay_type, eliminating offsetof() pointer arithmetic.
>> 
>> - Add __kernel_old_time_t typedef to tools/include/uapi/linux/time_types.h
>>   per Thomas's suggestion for backward compatibility with pre-v5.5
>>   UAPI headers.
>> 
>> - Factor out a common format_timespec() implementation shared by getdelays
>>   and delaytop, using strftime for cleaner timestamp formatting.
>> 
>> - Replace the complex sizeof/ULL/shift Y2038 guard with a direct narrowing
>>   truncation check ((long long)time_sec != ts->tv_sec).
>
>Thanks.  I can't figure out how to apply this, and neither can Sashiko:
>	https://sashiko.dev/#/patchset/20260829171238191s9SIXoZPTlZSmA2Px30hn@xxxxxxxxxx
>
>Seems there's a dependency on your "delaytop: add delay max, timestamp
>and sorting for top latency analysis" series which didn't get applied
>for reasons which I don't recall.

Hi Andrew,

Thanks for your reply!

You're right — this patch is part of a larger refactoring effort for
delaytop, so it does depend on the precursor series "delaytop: add
delay max, timestamp and sorting for top latency analysis".

I have read the discussion at the link below to figure out why the
precursor patch was reverted:
https://lore.kernel.org/all/20260804031240.D97F81F00A3E@xxxxxxxxxxxxxxx/

>From that thread, I understand that commit [1] ("delaytop: fix a bunch
of docs build problems") was reverted due to issues it introduced.
Consequently, this patch [2] ("delaytop: sort by max delay to highlight
top latency processes") was also reverted because it depended on the
documentation changes from [1].

If I resubmit patch [2] as-is, running make htmldocs will again
produce warnings in Documentation/accounting/delay-accounting.rst.
Those warnings (e.g., indentation and formatting issues in the rst
table) were originally fixed by [1], but since [1] is gone, they would
reappear.

My proposed solution is to update the next version of patch [2] to
include the necessary rst formatting fixes directly in that same patch.
This way, patch [2] no longer depends on [1] and can be applied
independently. The documentation fix would be part of this patch
rather than a separate precursor.

Thanks
Yaxin