From: Miklos Szeredi <miklos@szeredi.hu>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, linux-man <linux-man@vger.kernel.org>,
Alejandro Colomar <alx@kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, Karel Zak <kzak@redhat.com>,
Ian Kent <raven@themaw.net>, David Howells <dhowells@redhat.com>,
Christian Brauner <christian@brauner.io>,
Amir Goldstein <amir73il@gmail.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: proposed libc interface and man page for statmount(2)
Date: Fri, 17 Nov 2023 16:13:45 +0100 [thread overview]
Message-ID: <CAJfpegsCfuPuhtD+wfM3mUphqk9AxWrBZDa9-NxcdnsdAEizaw@mail.gmail.com> (raw)
In-Reply-To: <87leawphcj.fsf@oldenburg.str.redhat.com>
On Fri, 17 Nov 2023 at 15:47, Florian Weimer <fweimer@redhat.com> wrote:
> The strings could get fairly large if they ever contain key material,
> especially for post-quantum cryptography.
A bit far fetched, but okay.
> We have plenty of experience with these double-buffer-and-retry
> interfaces and glibc, and the failure mode once there is much more data
> than initially expected can be quite bad. For new interfaces, I want a
> way to avoid that. At least as long applications use statmount_allloc,
> we have a way to switch to a different interface if that becomes
> necessary just with a glibc-internal change.
Fair enough.
And that brings us to listmount(2) where I'm less sure that the
alloc+retry strategy is the right one. I still think that a namespace
with millions of mounts is unlikely, but it's not completely out of
the question. Also a listmount_alloc(3) API is less obvious since
the mount ID array as well as its size needs to be returned. So I'm
thinking whether it's a good idea to turn this into a
open/list/.../close style of interface in libc? We could do that in
the kernel as well, but I'm not sure it's worth it at this point.
Thanks,
Miklos
next prev parent reply other threads:[~2023-11-17 15:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-15 15:08 proposed libc interface and man page for statmount(2) Miklos Szeredi
2023-11-16 20:12 ` Adhemerval Zanella Netto
2023-11-16 20:36 ` Florian Weimer
2023-11-16 21:01 ` Miklos Szeredi
2023-11-17 14:22 ` Miklos Szeredi
2023-11-17 14:47 ` Florian Weimer
2023-11-17 15:13 ` Miklos Szeredi [this message]
2023-11-17 15:50 ` Miklos Szeredi
2023-11-20 11:55 ` Miklos Szeredi
2023-11-20 12:16 ` Florian Weimer
2023-11-20 12:34 ` Miklos Szeredi
2023-11-20 23:56 ` Ian Kent
2023-11-21 0:58 ` Ian Kent
2023-11-21 1:12 ` Ian Kent
2023-11-21 1:33 ` Ian Kent
2023-11-21 19:42 ` Miklos Szeredi
2023-11-21 20:42 ` Zack Weinberg
2023-11-21 23:28 ` Ian Kent
2023-11-22 16:18 ` Zack Weinberg
2023-11-21 23:07 ` Ian Kent
2023-11-22 10:18 ` Christian Brauner
2023-11-20 15:38 ` Christian Brauner
2023-11-20 15:30 ` Christian Brauner
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=CAJfpegsCfuPuhtD+wfM3mUphqk9AxWrBZDa9-NxcdnsdAEizaw@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=alx@kernel.org \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=fweimer@redhat.com \
--cc=kzak@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=raven@themaw.net \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).