Dear Steve,
Thanks for the review. I added name_len so the filename length could
be shown directly in the trace output.
However, it now seems redundant, since for a dynamic string field
like __string(name, ...), the length information is already maintained
by the trace event framework.
I will update the patch to remove name_len and send a v2 as soon as
possible. Thank you for the suggestion.
Best regards,
Baolin
在 2026/7/23 22:17, Steven Rostedt 写道:
On Thu, 23 Jul 2026 17:30:33 +0800
liubaolin <[email protected]> wrote:
Dear Steve,
dentry->d_name.len is the qstr length and does not include the
trailing NUL, so it corresponds to strlen(dentry->d_name.name), rather
than strlen(dentry->d_name.name) + 1.
But it is still tightly coupled with the actual length of the name.
If you think the extra name_len field here is unnecessary, I can submit
a v2 patch to drop it. Looking forward to your feedback.
I'm wondering what the purpose of it is for. The length of the string is
also stored in part of the meta data of the event which can be retrieved
via:
__get_dynnamic_array_len(name)
Although that will be strlen(name) + 1.
-- Steve
