On Mon, Sep 24, 2018 at 01:37:45PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > I have thought a little more about splitting up the mount flags into
> > sensible sets. I think the following four sets make sense:
> >
> > enum {
> > MOUNT_ATTR_PROPAGATION = 1,
> > MO
Christian Brauner wrote:
> I have thought a little more about splitting up the mount flags into
> sensible sets. I think the following four sets make sense:
>
> enum {
> MOUNT_ATTR_PROPAGATION = 1,
> MOUNT_ATTR_SECURITY,
> MOUNT_ATTR_SYNC,
> MOUNT_ATTR_TIME,
> };
On Mon, Sep 24, 2018 at 07:50:38AM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > 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_m
Christian Brauner wrote:
> 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
On Sun, Sep 23, 2018 at 11:45:17PM +0100, David Howells wrote:
> Christian Brauner 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 t
Christian Brauner 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 desc
On Sat, Sep 22, 2018 at 04:48:32PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > mount_setattr(int dfd, const char *path, unsigned int atflags,
> > unsigned int attr_cmd,
> > unsigned int attr_values,
> > unsigned int attr_mask);
>
> Whilst you ca
Christian Brauner wrote:
> mount_setattr(int dfd, const char *path, unsigned int atflags,
> unsigned int attr_cmd,
> unsigned int attr_values,
> unsigned int attr_mask);
Whilst you can have up to six arguments on a syscall, I seem to remember that
6-arg sysc
On Fri, Sep 21, 2018 at 05:52:36PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > So from reading the patch I got the impression that superblock mount
> > options passed via fsconfig() are passed as strings like "ro" and are
> > translated into approriate objects (e.g. flags etc.) b
Christian Brauner wrote:
> So from reading the patch I got the impression that superblock mount
> options passed via fsconfig() are passed as strings like "ro" and are
> translated into approriate objects (e.g. flags etc.) by the kernel.
I'm having second throughts about that - at least for "ro"
On Fri, Sep 21, 2018 at 04:07:55PM +0100, David Howells wrote:
> Miklos Szeredi wrote:
>
> > What happens if we introduce new flags for fsmount(2) and are already out
> > of flags for mount(2)? I see a big mess that way.
> >
> > So let's instead start a clean new set, to be used in the new API.
Miklos Szeredi wrote:
> Indeed. Also, shouldn't these include the propagation flags?
I guess so, though I'd be tempted to put those in a separate set. Also, I'm
not sure whether fsmount() should deal with prop flags or whether that should
be something move_mount() needs to deal with (ie. does
On Fri, Sep 21, 2018 at 5:07 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> What happens if we introduce new flags for fsmount(2) and are already out
>> of flags for mount(2)? I see a big mess that way.
>>
>> So let's instead start a clean new set, to be used in the new API.
>
> If we mus
Miklos Szeredi wrote:
> What happens if we introduce new flags for fsmount(2) and are already out
> of flags for mount(2)? I see a big mess that way.
>
> So let's instead start a clean new set, to be used in the new API.
If we must. But let's not call them just M_* please. Let's call them
MO
What happens if we introduce new flags for fsmount(2) and are already out
of flags for mount(2)? I see a big mess that way.
So let's instead start a clean new set, to be used in the new API.
The MS_RELATIME flag was accepted but ignored. Simply leave this out of
the new set, since "relatime" is
15 matches
Mail list logo