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: Wed, 14 Jan 2026 09:51:16 +0100 [thread overview]
Message-ID: <20260114085116.GB334250@pevik> (raw)
In-Reply-To: <CAEemH2d6=vmEKKf65WuAGRhfU4FE8mBf-dAzNWLmgYtFO3WA6Q@mail.gmail.com>
> > > I'd keep them separate from core library. For non-core libraries, I'd go
> > with
> > > something more distinct, like "ltp" prefix for file and function names.
> Thanks!
> > > When I look at "libnuma.h" I'd have to think for a bit if this is
> > > header from numa-devel
> > > or LTP. "ltpnuma.h" seems (to me) more clear that it's not LTP core
> > > nor numa-devel.
> Good point, but the ltp* prefix sounds too serious to me. Anything with
> the ltp* prefix inside an LTP makes me think it's critical information.
+1
> Perhaps we can use a lightweight name for the extra libs/:
> est_*: extra test library
> xst_*: extened test library
> lst_*: ltp test library
> I prefer to use lst_*, which is not only different from tst_*, but also
> implies
> this is ltp tst_ things.
> What do you think? or any better prefix?
Given that include "libfoo.h" should be local header and include <foo.h> should
be header from /usr/lib* I would be ok with either keep things as they are or
use the original Li's proposal.
For me personally is more useful to know whether header can be used in the old
API (i.e. "tst_" prefix means source is converted in the new C API) than whether
header is from extra library.
Kind regards,
Petr
> > > my 2 cents,
> > > Jan
> > That's exactly why I was suggesting to keep `tst_*`, which is more for
> > code-library. The `lib*` prefix is pretty generic and we need something
> > more specific for LTP.
> Indeed.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-01-14 8:51 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
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 [this message]
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=20260114085116.GB334250@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