From: Christian Brauner <brauner@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-man@vger.kernel.org,
linux-security-module@vger.kernel.org,
Karel Zak <kzak@redhat.com>, Ian Kent <raven@themaw.net>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <christian@brauner.io>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall
Date: Mon, 18 Sep 2023 16:40:43 +0200 [thread overview]
Message-ID: <20230918-stuhl-spannend-9904d4addc93@brauner> (raw)
In-Reply-To: <CAJfpegtaGXoZkMWLnk3PcibAvp7kv-4Yobo=UJj943L6v3ctJQ@mail.gmail.com>
On Mon, Sep 18, 2023 at 04:32:30PM +0200, Miklos Szeredi wrote:
> On Mon, 18 Sept 2023 at 16:25, Christian Brauner <brauner@kernel.org> wrote:
>
> > The system call should please have a proper struct like you had in your
> > first proposal. This is what I'm concerned about:
> >
> > int statmount(u64 mnt_id,
> > struct statmnt __user *st,
> > size_t size,
> > unsigned int flags)
> >
> > instead of taking an void pointer.
>
> So you are not concerned about having ascii strings returned by the
> syscall? I thought that was the main complaint.
I'm not following. The original proposals were only returning strings
even for basic binary data such as mount flags, propagation options, and
so on and we're using the xattr interface for any type of information.
What we're talking about here is a nicely typed struct which returns two
paths @mnt_root and @mnt_point which can both be represented as u64
pointers with length parameters like we do in other binary structs such
as bpf and clone3 and a few others. That is a compromise I can live
with. I'm really trying to find as much common ground here as we can.
next prev parent reply other threads:[~2023-09-18 15:33 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-13 15:22 [RFC PATCH 0/3] quering mount attributes Miklos Szeredi
2023-09-13 15:22 ` [RFC PATCH 1/3] add unique mount ID Miklos Szeredi
2023-09-14 9:03 ` Christian Brauner
2023-09-14 9:30 ` Miklos Szeredi
2023-09-14 9:36 ` Christian Brauner
2023-09-14 9:43 ` Miklos Szeredi
2023-09-14 10:06 ` Christian Brauner
2023-09-15 1:31 ` Ian Kent
2023-09-13 15:22 ` [RFC PATCH 2/3] add statmnt(2) syscall Miklos Szeredi
2023-09-14 6:11 ` Amir Goldstein
2023-09-15 1:05 ` Ian Kent
2023-09-14 9:27 ` Christian Brauner
2023-09-14 10:13 ` Miklos Szeredi
2023-09-14 15:26 ` Christian Brauner
2023-09-15 8:56 ` Miklos Szeredi
2023-09-18 13:51 ` Christian Brauner
2023-09-18 14:14 ` Miklos Szeredi
2023-09-18 14:24 ` Christian Brauner
2023-09-18 14:32 ` Miklos Szeredi
2023-09-18 14:40 ` Christian Brauner [this message]
2023-09-18 14:51 ` Miklos Szeredi
2023-09-18 15:22 ` Christian Brauner
2023-09-18 15:39 ` Miklos Szeredi
2023-09-19 0:37 ` Matthew House
2023-09-19 8:02 ` Miklos Szeredi
2023-09-19 9:07 ` Christian Brauner
2023-09-19 10:51 ` Miklos Szeredi
2023-09-19 12:41 ` Christian Brauner
2023-09-19 12:59 ` Miklos Szeredi
2023-09-19 13:18 ` Christian Brauner
2023-09-19 21:28 ` Matthew House
2023-09-20 9:42 ` Miklos Szeredi
2023-09-20 13:26 ` Matthew House
2023-09-21 7:34 ` Miklos Szeredi
2023-09-26 13:48 ` Florian Weimer
2023-09-26 14:06 ` Miklos Szeredi
2023-09-26 14:19 ` Florian Weimer
2023-09-26 14:33 ` Miklos Szeredi
2023-09-26 14:39 ` Florian Weimer
2023-09-26 14:36 ` Christian Brauner
2023-09-26 14:13 ` Christian Brauner
2023-09-18 20:58 ` Andreas Dilger
2023-09-19 12:50 ` Christian Brauner
2023-09-20 0:33 ` Dave Chinner
2023-09-18 14:29 ` Jeff Layton
2023-09-18 14:35 ` Christian Brauner
2023-09-20 9:43 ` David Laight
2023-09-14 20:39 ` Paul Moore
2023-09-15 9:10 ` Miklos Szeredi
2023-09-17 18:18 ` Sargun Dhillon
2023-09-17 23:36 ` Ian Kent
2023-09-18 13:05 ` Christian Brauner
2023-09-25 12:57 ` Arnd Bergmann
2023-09-25 13:04 ` Christian Brauner
2023-09-25 13:13 ` Miklos Szeredi
2023-09-25 13:19 ` Christian Brauner
2023-09-25 13:20 ` Miklos Szeredi
2023-09-25 15:46 ` Arnd Bergmann
2023-09-26 10:05 ` Christian Brauner
2023-09-27 8:46 ` Miklos Szeredi
2023-09-13 15:22 ` [RFC PATCH 3/3] add listmnt(2) syscall Miklos Szeredi
2023-09-14 6:00 ` Amir Goldstein
2023-09-14 8:50 ` Miklos Szeredi
2023-09-14 10:01 ` Christian Brauner
2023-09-15 1:00 ` Ian Kent
2023-09-17 0:54 ` Matthew House
2023-09-17 14:32 ` Miklos Szeredi
2023-09-18 13:15 ` Christian Brauner
2023-09-19 16:47 ` Paul Moore
2023-09-28 10:07 ` Miklos Szeredi
2023-10-04 19:22 ` Paul Moore
2023-09-14 6:47 ` [RFC PATCH 0/3] quering mount attributes Amir Goldstein
2023-09-15 1:20 ` Ian Kent
2023-09-15 3:06 ` Amir Goldstein
2023-09-16 2:04 ` Ian Kent
2023-09-16 2:19 ` Ian Kent
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=20230918-stuhl-spannend-9904d4addc93@brauner \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=kzak@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@redhat.com \
--cc=raven@themaw.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).