On Tue, Jun 25, 2024 at 10:17:56AM GMT, Josef Bacik wrote:
> 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@xxxxxxxxxxxxxx> 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,
Honestly, I don't have a strong opinion on this. Both the ','
and \0 options work for me, and the userspace is already set up for
','.
Using \0 is a possibility for creating an ideal kernel interface as it
doesn't require escaping, but it may require significant changes to the
kernel with minimal advantage for userspace.
By the way, starmount() is so flexible that adding support for other
formats can be done anytime later with some new STATMOUNT_* mask.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
