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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.