From: Cyril Hrubis <chrubis@suse.cz>
To: Li Wang <li.wang@linux.dev>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] lib: Introduce tst_path.h to consolidate system paths
Date: Mon, 4 May 2026 17:11:46 +0200 [thread overview]
Message-ID: <afi3Ml5vFv2irnc0@yuki.lan> (raw)
In-Reply-To: <20260504133020.14129-1-li.wang@linux.dev>
Hi!
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) Linux Test Project, 2026
> + * Copyright (c) 2026 Li Wang <li.wang@linux.dev>
> + */
> +
> +#ifndef TST_PATH__
> +#define TST_PATH__
> +
> +/* PROC */
> +#define PROC_SYS_VM "/proc/sys/vm/"
> +#define PROC_SYS_FS "/proc/sys/fs/"
> +#define PROC_SYS_NET "/proc/sys/net/"
> +#define PROC_SYS_USER "/proc/sys/user/"
> +#define PROC_SYS_KERNEL "/proc/sys/kernel/"
> +/* SYS */
> +#define SYS_KERNEL_MM "/sys/kernel/mm/"
I wonder if this is really better. The macro name is not shorter and the
kernel path is not going to change since it's part of API.
> +
> +/* VM */
> +#define PATH_VM_NR_HPAGES PROC_SYS_VM "nr_hugepages"
> +#define PATH_VM_OC_HPAGES PROC_SYS_VM "nr_overcommit_hugepages"
> +#define PATH_VM_DROP_CACHES PROC_SYS_VM "drop_caches"
> +#define PATH_VM_COMPACT_MEMORY PROC_SYS_VM "compact_memory"
> +
> +/* HUGETLB */
> +#define PATH_MM_HUGEPAGES SYS_KERNEL_MM "hugepages/"
> +#define PATH_MM_THP SYS_KERNEL_MM "transparent_hugepage/"
These make more sense since the path is long and the macro makes it
shorter.
> +/* KSM */
> +#define PATH_MM_KSM SYS_KERNEL_MM "ksm/"
> +#define MM_KSM_FP(s) (PATH_MM_KSM s)
> +
> +/* NETWORK */
> +#define PATH_NET_IPV4 PROC_SYS_NET "ipv4/"
> +#define NET_IPV4_FP(s) (PATH_NET_IPV4 s)
> +
> +/* MEMINFO */
> +#define MEMINFO_HPAGE_TOTAL "HugePages_Total:"
> +#define MEMINFO_HPAGE_FREE "HugePages_Free:"
> +#define MEMINFO_HPAGE_RSVD "HugePages_Rsvd:"
> +#define MEMINFO_HPAGE_SURP "HugePages_Surp:"
> +#define MEMINFO_HPAGE_SIZE "Hugepagesize:"
> +
> +#endif /* TST_PATH_H */
> diff --git a/include/tst_test.h b/include/tst_test.h
> index f12c59f39..4898cfe4c 100644
> --- a/include/tst_test.h
> +++ b/include/tst_test.h
> @@ -26,6 +26,7 @@
> #include "tst_mkfs.h"
> #include "tst_fs.h"
> #include "tst_pid.h"
> +#include "tst_path.h"
> #include "tst_cmd.h"
> #include "tst_cpu.h"
> #include "tst_process_state.h"
> diff --git a/lib/newlib_tests/test19.c b/lib/newlib_tests/test19.c
> index a5683eaa4..0a7766192 100644
> --- a/lib/newlib_tests/test19.c
> +++ b/lib/newlib_tests/test19.c
> @@ -10,7 +10,7 @@
>
> static void setup(void)
> {
> - SAFE_FILE_PRINTF("/proc/sys/kernel/core_pattern", "changed");
> + SAFE_FILE_PRINTF(PROC_SYS_KERNEL "core_pattern", "changed");
> tst_sys_conf_dump();
> }
>
> @@ -25,8 +25,8 @@ static struct tst_test test = {
> .setup = setup,
> .save_restore = (const struct tst_path_val[]) {
> {"/proc/nonexistent", NULL, TST_SR_SKIP},
> - {"/proc/sys/kernel/numa_balancing", NULL, TST_SR_TBROK},
> - {"/proc/sys/kernel/core_pattern", NULL, TST_SR_TCONF},
> + {PROC_SYS_KERNEL "numa_balancing", NULL, TST_SR_TBROK},
> + {PROC_SYS_KERNEL "core_pattern", NULL, TST_SR_TCONF},
This is exactly what I'm unsure about, it's not shorter, nor more
readable.
Maybe if this was PATH_NUMA_BALANCING and PATH_CORE_PATTERN it would be
shorter and would make much more sense.
Shortening this to SYS_KERNEL("numa_balancing") would be confusing since
we have both /proc/sys/ and /sys/
...
> diff --git a/testcases/kernel/mem/ksm/ksm01.c b/testcases/kernel/mem/ksm/ksm01.c
> index be03f943f..d61ac77b5 100644
> --- a/testcases/kernel/mem/ksm/ksm01.c
> +++ b/testcases/kernel/mem/ksm/ksm01.c
> @@ -74,13 +74,13 @@ static struct tst_test test = {
> },
> .setup = setup,
> .save_restore = (const struct tst_path_val[]) {
> - {"/sys/kernel/mm/ksm/run", NULL, TST_SR_TBROK},
> - {"/sys/kernel/mm/ksm/sleep_millisecs", NULL, TST_SR_TBROK},
> - {"/sys/kernel/mm/ksm/max_page_sharing", NULL,
> + {MM_KSM_FP("run"), NULL, TST_SR_TBROK},
> + {MM_KSM_FP("sleep_millisecs"), NULL, TST_SR_TBROK},
> + {MM_KSM_FP("max_page_sharing"), NULL,
> TST_SR_SKIP_MISSING | TST_SR_TCONF_RO},
> - {"/sys/kernel/mm/ksm/merge_across_nodes", "1",
> + {MM_KSM_FP("merge_across_nodes"), "1",
> TST_SR_SKIP_MISSING | TST_SR_TCONF_RO},
> - {"/sys/kernel/mm/ksm/smart_scan", "0",
> + {MM_KSM_FP("smart_scan"), "0",
> TST_SR_SKIP_MISSING | TST_SR_TBROK_RO},
> {}
> },
These looks reasonable.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-05-04 15:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 13:51 [LTP] [PATCH] lib: Introduce tst_path.h to consolidate system paths Li Wang
2026-05-04 13:30 ` [LTP] [PATCH v2] " Li Wang
2026-05-04 14:08 ` [LTP] " linuxtestproject.agent
2026-05-04 15:11 ` Cyril Hrubis [this message]
2026-05-05 3:04 ` [LTP] [PATCH v2] " Li Wang
2026-05-05 7:00 ` Cyril Hrubis
2026-05-05 7:13 ` Li Wang
2026-05-15 15: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=afi3Ml5vFv2irnc0@yuki.lan \
--to=chrubis@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