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 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.