From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: Pradeep Susarla <pradeep.susarla@gmail.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] libs: adopt lib* prefix instead of tst_* for libs/
Date: Tue, 13 Jan 2026 12:51:48 +0100 [thread overview]
Message-ID: <20260113115148.GA314748@pevik> (raw)
In-Reply-To: <CAEemH2c-Maht3X7Qu5Shv+amXVWJaU2NKsCYdzNE2t9jnoWbzw@mail.gmail.com>
> Hi Andrea, All,
> On Mon, Jan 12, 2026 at 8:59 PM Andrea Cervesato <andrea.cervesato@suse.com>
> wrote:
> > Hi!
> > I generally agree with this approach, but I have the feeling we are
> > mixing naming a bit here. For instance, we have headers like ipcmsg.h
> > that has no functions starting with tst_*, while tst_numa.h does. Also,
> > the tst_* prefix for files has the clear goal to state we are importing
> > some LTP functionalities inside the tests code.
> > Said so, I would rather rename all LTP libraries as tst_*.h and to
> > rename functions inside them with tst_* prefix. In this way, we know
> > at the very first look, when a library is imported from LTP and not
> > from other sources.
'tst_' prefix is only for *new* C API. That's why ipcmsg.h/libs/ipc/libipc.c
don't use it. I would prefer to keep that way (not use 'tst_' for legacy C API
library source).
That's why I quite like Li's approach (I'm ok if libs/ sources' headers will
have 'lib' prefix instead of 'tst_'), although I liked more
libs/sigwait/sigwait.c than libs/sigwait/libsigwait.c.
> I indeed thought about all use tst_* for those global header files.
> But to distinguish lib/ with libs/ I finally feel that libs/ is not the
> core LTP API
> and sometimes built only when they are needed, if we rename all these
> header file with tst_* that will mislead people to find the *.c file in
> lib/, which
> is not the right place.
> So in my patch, keep define tst_* only for the core LTP API, and lib* prefix
> reserve for libs/ that will be clear at a glance.
+1
> Or, if go with tst_*.h for all (and rename functions with tst_*), I think
> the libs/ should be merged into lib/.
I don't think this would be good. It would require also changing a build system,
touch too many files. And I don't even see a benefit for a such change.
Kind regards,
Petr
> @Cyril, Petr, any comments?
I also wonder Cyril's and Jan's opinion.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-01-13 11:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 2:39 [LTP] [PATCH] libs: adopt lib* prefix instead of tst_* for libs/ Li Wang via ltp
2026-01-09 3:07 ` Li Wang via ltp
2026-01-12 12:59 ` Andrea Cervesato via ltp
2026-01-12 14:10 ` Li Wang via ltp
2026-01-13 11:51 ` Petr Vorel [this message]
2026-01-13 13:30 ` Jan Stancek via ltp
2026-01-13 13:41 ` Andrea Cervesato via ltp
2026-01-14 3:03 ` Li Wang via ltp
2026-01-14 8:51 ` Petr Vorel
2026-01-14 10:32 ` Li Wang via ltp
2026-01-14 11:33 ` Petr Vorel
2026-01-14 11:58 ` Li Wang via ltp
2026-01-14 12:18 ` Jan Stancek via ltp
2026-01-14 12:07 ` Andrea Cervesato via ltp
2026-01-14 12:47 ` Li Wang via ltp
2026-01-14 13:36 ` Andrea Cervesato via ltp
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=20260113115148.GA314748@pevik \
--to=pvorel@suse.cz \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=pradeep.susarla@gmail.com \
/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