All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v6 2/2] syscalls/fsmount01: Add test for new mount API v5.2
Date: Mon, 17 Feb 2020 10:43:48 +0100	[thread overview]
Message-ID: <20200217094348.GB13398@dell5510> (raw)
In-Reply-To: <1181359180.7790231.1581931018783.JavaMail.zimbra@redhat.com>

Hi Jan,

...
> > > BTW, I like the way Viresh Kumar gives in his fsmount.h, it looks more
> > > tidy
> > > > and clean.
> > > > http://lists.linux.it/pipermail/ltp/2020-February/015413.html
> > > Hm, competing implementations.
> > > Both tries to handle preventing redefinitions (e.g. FSOPEN_CLOEXEC) once
> > > the API hits libc headers (at least in musl it might be soon).
> > > Zorro tries to bind them to function check (e.g. #ifndef HAVE_FSMOUNT,
> > > #ifndef
> > > HAVE_MOVE_MOUNT), Viresh just use single check #ifndef OPEN_TREE_CLONE.
> > > I slightly prefer Viresh way (it's unlikely that libc headers would
> > > include just

> > +1 Viresh way.


> > > part of the new mount API definitions, although obviously the most safest
> > > way
> > > would be to either guard with #ifndef each definition or just give up on
> > > testing
> > > header and copy whole include/uapi/linux/mount.h (+ avoid using
> > > sys/mount.h;
> > > that's the way used for include/lapi/bpf.h).


> > @Cyril, @Jan, any else suggestion?

> I'd go with additions to lapi, and avoid copying entire linux/mount.h. And use
> #ifndef for each definition. v7 is currently not doing that, but it's easy
> to add if we run into problems later, when/if there are additions to mount API.
OK, I'm also for single guard with OPEN_TREE_CLONE until anything else is
needed. I'll add your ack for lapi commit.

Kind regards,
Petr

  reply	other threads:[~2020-02-17  9:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 14:41 [LTP] [PATCH v6 1/2] safe_macros: Use tst_umount() in safe_umount() Petr Vorel
2020-02-07 14:41 ` [LTP] [PATCH v6 2/2] syscalls/fsmount01: Add test for new mount API v5.2 Petr Vorel
2020-02-16  7:32   ` Li Wang
2020-02-16 13:17     ` Petr Vorel
2020-02-17  6:48       ` Li Wang
2020-02-17  7:51         ` Petr Vorel
2020-02-17  9:16         ` Jan Stancek
2020-02-17  9:43           ` Petr Vorel [this message]
2020-02-17  7:17       ` Li Wang
2020-02-17  8:04     ` Viresh Kumar
2020-02-07 15:24 ` [LTP] [PATCH v6 1/2] safe_macros: Use tst_umount() in safe_umount() Cyril Hrubis
2020-02-07 15:47   ` Jan Stancek
2020-02-07 15:53     ` Petr Vorel
2020-02-07 15:56       ` Jan Stancek
2020-02-07 15:57     ` Cyril Hrubis
2020-02-07 16:10       ` Petr Vorel
2020-02-10  8:19       ` Jan Stancek
2020-02-10 12:44         ` Petr Vorel

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=20200217094348.GB13398@dell5510 \
    --to=pvorel@suse.cz \
    --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.