From: Li Wang <li.wang@linux.dev>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3] lib: Introduce tst_path_macros.h to consolidate system paths
Date: Sat, 16 May 2026 13:00:14 +0800 [thread overview]
Message-ID: <agf53mSShy735Whu@linux.dev> (raw)
In-Reply-To: <20260515155814.GB45497@pevik>
Petr Vorel wrote:
> Hi Li,
>
> could you please rebase to master and push branch to your fork?
> Patch now does not apply:
Sure, rebased and pushed to my fork:
https://github.com/wangli5665/ltp/tree/tst_path_defs
> I suppose metadata will work with it correctly since Cyril's support for macros
> in past (i.e. metadata/ltp.json will have "/proc/sys/kernel/hostname", not
> PATH_HOSTNAME, which tells nothing to LTP users).
Oh, I didn't realized this, seems the ltp.json contains define words:
# cat metadata/ltp.json |grep PATH_
"PATH_MAX_USER_NAMESPACES",
"PATH_MAX_USER_NAMESPACES",
"PATH_MAX_USER_NAMESPACES",
"PATH_MAX_USER_NAMESPACES",
"PATH_UNPRIVILEGED_USERNS_CLONE",
"PATH_MAX_USER_NAMESPACES",
"PATH_UNPRIVILEGED_USERNS_CLONE",
"PATH_VM_OVERCOMMIT_HPAGES",
"PATH_VM_OVERCOMMIT_HPAGES",
...
I can change them back to the original types (for ltp.json) in a separate patch.
> I slightly prefer the previous name tst_path.h (for me macros are complex
> functions, not just simple definitions, what info gives me "macro-only content"?
> I care more about the actual content). I'm ok with it current name, but maybe
> kernel_paths.h or proc_sys_paths.h would be more obvious which paths is it
> about. Also, it's not just about paths, but also about the content in these
> /proc|sys files (e.g. "HugePages_Total:").
Yes, I'm also hesitant about the naming. The tst_ prefix is needed since it will
be placed in the include/ directory and used across the entire project. proc_ or
sys_ sounds a bit too narrow in scope. Maybe:
tst_path_defs.h
tst_sys_paths.h
I'm now leaning towards tst_path_defs.h. WDYT?
>
> > * Replaced generic string concatenation macros with explicit.
> > * Manualy built & Tested all touched tests on my c10s vm.
>
> ...
>
> > +/* KERNEL */
> > +#define PATH_HOSTNAME "/proc/sys/kernel/hostname"
> > +#define PATH_OSRELEASE "/proc/sys/kernel/osrelease"
> ...
> > +/* USER */
> > +#define PATH_MAX_USER_NAMESPACES "/proc/sys/user/max_user_namespaces"
>
> I have 2 concerns:
>
> 1) we often try to have LTP specific 'TST_' prefix to avoid clash with
> whatever definition. Is it ok to ignore it now?
I'd prefer to stick with PATH_ instead of TST_PATH_. PATH_ is universally
understood as a file path definition. Adding TST_ makes it unnecessarily
verbose.
> 2) I'm pretty sure I will have to look into this file often, because from
> definition name I have no idea where exactly file is. I'd be ok with long name
> TST_PROC_SYS_KERNEL_HOSTNAME, but understand Cyril wants short names. Maybe at
> least TST_PATH_KERNEL_HOSTNAME and TST_PATH_USER_MAX_USER_NAMESPACES(last
> directory and file)? That would be similar to what sysctl is using:
>
> sysctl kernel.hostname
> sysctl user.max_user_namespaces
I understand the concern, but long macros like TST_PATH_USER_MAX_USER_NAMESPACES
will make the test code very verbose and easily lead to 80-character
line wrapping issues.
To address the readability issue without making the names too long,
I can add _KERNEL_ and _USER_ to the defines (like PATH_KERNEL_HOSTNAME
and PATH_USER_MAX_USER_NAMESPACES). I think this is a good middle ground.
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2026-05-16 5:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 8:30 [LTP] [PATCH v3] lib: Introduce tst_path_macros.h to consolidate system paths Li Wang
2026-05-05 17:54 ` [LTP] " linuxtestproject.agent
2026-05-15 15:58 ` [LTP] [PATCH v3] " Petr Vorel
2026-05-16 5:00 ` Li Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agf53mSShy735Whu@linux.dev \
--to=li.wang@linux.dev \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox