From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 1/2] openat2: define _GNU_SOURCE and include <fcntl.h>
Date: Thu, 5 Feb 2026 11:08:25 +0100 [thread overview]
Message-ID: <20260205100825.GB294817@pevik> (raw)
In-Reply-To: <aYP2AxZJeXgEDMpA@redhat.com>
> On Wed, Feb 04, 2026 at 11:27:53PM +0100, Petr Vorel wrote:
> > Hi Li,
> > ...
> > > > lapi/openat2.h uses struct open_how directly, shouldn't be included lapi/fcntl.h
> > > > there?
> > > From my understand lapi/* are appendix for missing stuff in header file.
> > Yes, but we agreed in the past, that it's better to include relevant libc/kernel
> > header in the lapi header [1]:
> > LAPI header should always include original header.
> > [1] https://github.com/linux-test-project/ltp/blob/master/doc/old/C-Test-API.asciidoc#lapi-headers
> > I thought we had a discussion about it, but now I see nobody acked the change in
> > ML (cfbc41d775), therefore I somehow pushed this approach without consensus with
> > others. I'm sorry for that, we can revise that. At the moment quite a few lapi
> > headers use this approach (likely majority).
> > IMHO it's better to include it than expect that all tests which use lapi header
> > will include relevant header *before* (otherwise tests can happily always depend
> > on fallback instead of using a real value from a system header).
> Yes, I generally agree with this, and here is my understand:
> 1. Testcase should include original <header.h> (but not "lapi/header.h")
> if *only* need the original <header.h> file.
... and don't need any fallback from the lapi header.
> 2. LAPI-header should always include original <header.h>, it handling
> the missing/conflicting part there.
> Thus, we can treat "lapi/header.h" as a patched <header.h> and only
> use it intead of the original <header.h> in testcase if needed.
+1
> 3. We avoid including both original <header.h> and "lapi/header.h" in
> testase at the same time.
+1
> > It's a minor detail, but being consistent helps for newcomers to understand
> > LTP code.
> > And *if* we agree on it, it should be now doc/developers/ground_rules.rst.
> > Also there is a different approach where should be fallbacks. We use some lapi
> > headers (e.g. lapi/openat2.h but there are more) which don't have public
> > equivalent in libc (/usr/include/bits/openat2.h cannot be used directly, but via
> > <fcntl.h>). Therefore I would put content of lapi/openat2.h into lapi/fcntl.h,
> > but that's a minor detail.
> I am ok with it, the advantage merge lapi/openat2.h into lapi/fcntl.h is
> keep things more centralized.
> But also, keep lapi/openat2.h seperated is more modular, and it should
> contains <fcntl.h> as well.
Yeah, I don't have strong opinion about it, both ways would work.
> > > Test cases should only include standard header files, and lapi should
> > > only be used in case of missing or conflicting header files.
> > But lapi/openat2.h also uses struct open_how. I would either include <fcntl.h>
> > in both sources or just in lapi/openat2.h. Having it only in tests looks to me
> > as not ideal.
> Right, thanks for bring up this topic.
Thank you for your time. I try to send a patch to add the outcome to
doc/developers/ground_rules.rst and wait for ack of others to get broader
consensus about it.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-02-05 10:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 2:43 [LTP] [PATCH v2 1/2] openat2: define _GNU_SOURCE and include <fcntl.h> Li Wang via ltp
2026-02-03 2:43 ` [LTP] [PATCH v2 2/2] newlib_tests: add tst_filesystems01 to .gitignore Li Wang via ltp
2026-02-04 11:57 ` Petr Vorel
2026-02-04 12:05 ` Li Wang via ltp
2026-02-04 12:26 ` Petr Vorel
2026-02-04 12:23 ` [LTP] [PATCH v2 1/2] openat2: define _GNU_SOURCE and include <fcntl.h> Petr Vorel
2026-02-04 14:20 ` Li Wang via ltp
2026-02-04 22:27 ` Petr Vorel
2026-02-05 1:44 ` Li Wang via ltp
2026-02-05 10:08 ` Petr Vorel [this message]
2026-02-05 10:33 ` Li Wang 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=20260205100825.GB294817@pevik \
--to=pvorel@suse.cz \
--cc=liwang@redhat.com \
--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.