Linux Test Project
 help / color / mirror / Atom feed
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

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox