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