All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Karel Zak <kzak@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 0/4] Add the ability to query mount options in statmount
Date: Tue, 25 Jun 2024 10:17:56 -0400	[thread overview]
Message-ID: <20240625141756.GA2946846@perftesting> (raw)
In-Reply-To: <5j2codcdntgdt4wpvzgbadg4r5obckor37kk4sglora2qv5kwu@wsezhlieuduj>

On Tue, Jun 25, 2024 at 03:52:03PM +0200, Karel Zak wrote:
> On Tue, Jun 25, 2024 at 03:35:17PM GMT, Christian Brauner wrote:
> > On Tue, Jun 25, 2024 at 03:04:40PM GMT, Miklos Szeredi wrote:
> > > On Tue, 25 Jun 2024 at 15:00, Josef Bacik <josef@toxicpanda.com> wrote:
> > > 
> > > > We could go this way I suppose, but again this is a lot of work, and honestly I
> > > > just want to log mount options into some database so I can go looking for people
> > > > doing weird shit on my giant fleet of machines/containers.  Would the iter thing
> > > > make the overlayfs thing better?  Yeah for sure.  Do we care?  I don't think so,
> > > > we just want all the options, and we can all strsep/strtok with a comma.
> > > 
> > > I think we can live with the monolithic option block.  However I'd
> > > prefer the separator to be a null character, thus the options could be
> > > sent unescaped.  That way the iterator will be a lot simpler to
> > > implement.
> > 
> > For libmount it means writing a new parser and Karel prefers the ","
> > format so I would like to keep the current format.
>  
> Sorry for the misunderstanding. I had a chat with Christian about it
> when I was out of my office (and phone chats are not ideal for this).
> 
> I thought Miklos had suggested using a space (" ") as the separator, but
> after reading the entire email thread, I now understand that Miklos'
> suggestion is to use \0 (zero) as the options separator.
> 
> I have no issue with using \0, as it will make things much simpler.

What I mean was "we can all strsep/strtok with a comma" I meant was in
userspace.  statmount() gives you the giant block, it's up to user space to
parse it.

I can change the kernel to do this for you, and then add a mnt_opts_len field so
you know how big of a block you get.

But that means getting the buffer, and going back through it and replacing every
',' with a '\0', because I'm sure as hell not going and changing all of our
->show_options() callbacks to not put in a ','.

Is this the direction we want to go?  Thanks,

Josef

  parent reply	other threads:[~2024-06-25 14:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-24 19:40 [PATCH 0/4] Add the ability to query mount options in statmount Josef Bacik
2024-06-24 19:40 ` [PATCH 1/4] fs: rename show_mnt_opts -> show_vfsmnt_opts Josef Bacik
2024-06-24 19:40 ` [PATCH 2/4] fs: add a helper to show all the options for a mount Josef Bacik
2024-06-25 14:16   ` Christian Brauner
2024-06-26  7:47     ` Karel Zak
2024-06-24 19:40 ` [PATCH 3/4] fs: export mount options via statmount() Josef Bacik
2024-06-24 19:40 ` [PATCH 4/4] sefltests: extend the statmount test for mount options Josef Bacik
2024-06-24 19:53 ` [PATCH 0/4] Add the ability to query mount options in statmount Jeff Layton
2024-06-25 10:42 ` Christian Brauner
2024-06-25 13:00   ` Josef Bacik
2024-06-25 13:04     ` Miklos Szeredi
2024-06-25 13:35       ` Christian Brauner
2024-06-25 13:52         ` Karel Zak
2024-06-25 13:55           ` Christian Brauner
2024-06-25 14:17           ` Josef Bacik [this message]
2024-06-26  7:34             ` Karel Zak
2024-06-26 12:23             ` Miklos Szeredi
2024-11-11 13:12               ` Miklos Szeredi
2024-11-11 13:29                 ` Christian Brauner
2024-11-11 13:47                   ` Miklos Szeredi
2024-11-11 15:28                 ` Josef Bacik
2024-11-11 16:02                   ` Miklos Szeredi
2024-11-12  8:54                     ` Karel Zak
2024-06-26 12:03 ` (subset) " 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=20240625141756.GA2946846@perftesting \
    --to=josef@toxicpanda.com \
    --cc=brauner@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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.