From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] lib: Introduce tst_path.h to consolidate system paths
Date: Fri, 15 May 2026 17:32:50 +0200 [thread overview]
Message-ID: <20260515153250.GA45497@pevik> (raw)
In-Reply-To: <afi3Ml5vFv2irnc0@yuki.lan>
> 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.
IMHO it's not about kernel change but about user typos :).
I prefer constants (build failure in case of typo instead of wrong patch being
hidden for years).
I thought in the past about replacing tag keys ("linux-git", "glibc-git", ...)
with constants, but never implement it as I expected it'd be rejected as
useless.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2026-05-15 15:33 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 ` [LTP] [PATCH v2] " Cyril Hrubis
2026-05-05 3:04 ` Li Wang
2026-05-05 7:00 ` Cyril Hrubis
2026-05-05 7:13 ` Li Wang
2026-05-15 15:32 ` Petr Vorel [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=20260515153250.GA45497@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--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.