lkml.org 
[lkml]   [2018]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/6] fsmount: do not use legacy MS_ flags
On Sun, Sep 23, 2018 at 11:45:17PM +0100, David Howells wrote:
> Christian Brauner <christian@brauner.io> wrote:
>
> > Of course, I'm not sure what the reasons for all of the other arguments to
> > this function are since it's not yet implemented.
>
> Well, dfd, path and atflags are pretty standard. atflags conveys things like
> AT_EMPTY_PATH or AT_SYMLINK_NOFOLLOW and dfd conveys a file descriptor
> pointing to a vfs object or AT_FDCWD.
>
> > Seems that attr_values and attr_mask could be compacted to a single
> > attr_mask maybe?
>
> If you don't have a mask, you can't really do recursion. Without the mask,
> you have to supply the entire set of options absolutely - and this would get
> stamped on everything in the target range.
>
> With a mask in combination with the set of desired values, you can turn on or
> off a specific subset of the attributes without affecting the rest - without
> needing to know the rest.

Ok, understood. What about passing the different attrs as a struct?

struct mount_attr {
unsigned int attr_cmd,
unsigned int attr_values,
unsigned int attr_mask,

};

mount_setattr(int dfd, const char *path, unsigned int atflags,
struct mount_attr *attr);

I find that to be a little cleaner in all honesty.
One could also add a version argument similar to what we currently do
for vfs fcaps so that kernel and userspace can easily navigate
compabitility when a new member gets added or removed in later releases.

Christian
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-09-24 01:02    [W:3.050 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site