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,
> >
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,
> >
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,
> };
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
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
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
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
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
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
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
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
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
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
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
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
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.)
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.)
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
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
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
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
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
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
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
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
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
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"
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"
30 matches
Mail list logo
