From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <li.wang@linux.dev>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3] lib: Introduce tst_path_macros.h to consolidate system paths
Date: Fri, 15 May 2026 17:58:14 +0200 [thread overview]
Message-ID: <20260515155814.GB45497@pevik> (raw)
In-Reply-To: <20260505083016.36843-1-li.wang@linux.dev>
Hi Li,
could you please rebase to master and push branch to your fork?
Patch now does not apply:
Description: [v3] lib: Introduce tst_path_macros.h to consolidate system paths
Applying: lib: Introduce tst_path_macros.h to consolidate system paths
error: patch failed: testcases/kernel/syscalls/newuname/newuname01.c:31
error: testcases/kernel/syscalls/newuname/newuname01.c: patch does not apply
Which is strange, I'm trying to apply on 1e619620eda111cbd94672dd5a0e1cc92567b15d~
(prior Cyril's changes to newuname01.c).
Ideally your for always had rebased version.
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).
> We have a lot of hardcoded strings and duplicated macros for /proc
> and /sys paths scattered throughout the testcases.
> This patch introduces a new common header, tst_path_macros.h, to centralize
> and standardize these path definitions. By unifying these macros, we
> reduce code duplication, improve maintainability, and ensure consistent
> path usage across the entire LTP codebase.
> Signed-off-by: Li Wang <li.wang@linux.dev>
> ---
> Notes:
> v3:
> * Rename to tst_path_macros.h to reflect its macro-only content.
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:").
> * 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?
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
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-05-15 15:58 UTC|newest]
Thread overview: 7+ 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 ` Petr Vorel [this message]
2026-05-16 5:00 ` [LTP] [PATCH v3] " Li Wang
2026-05-16 17:15 ` Petr Vorel
2026-05-17 2:28 ` Li Wang
2026-05-20 9:32 ` Petr Vorel
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=20260515155814.GB45497@pevik \
--to=pvorel@suse.cz \
--cc=li.wang@linux.dev \
--cc=ltp@lists.linux.it \
/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