Re: [PATCH 06/14] VFS: Implement fsmount() to effect a pre-configured mount [ver #6]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 10, 2017 at 03:38:21PM +0200, Miklos Szeredi wrote:
> On Tue, Oct 10, 2017 at 11:51 AM, Karel Zak <kzak@xxxxxxxxxx> wrote:
> > On Tue, Oct 10, 2017 at 10:00:01AM +0200, Miklos Szeredi wrote:
> >> > +
> >> > +       if (flags & MS_RDONLY)
> >> > +               mnt_flags |= MNT_READONLY;
> >> > +       if (flags & MS_NOSUID)
> >> > +               mnt_flags |= MNT_NOSUID;
> >> > +       if (flags & MS_NODEV)
> >> > +               mnt_flags |= MNT_NODEV;
> >> > +       if (flags & MS_NOEXEC)
> >> > +               mnt_flags |= MNT_NOEXEC;
> >> > +       if (flags & MS_NODIRATIME)
> >> > +               mnt_flags |= MNT_NODIRATIME;
> >> > +
> >> > +       if (flags & MS_STRICTATIME) {
> >> > +               if (flags & MS_NOATIME)
> >> > +                       return -EINVAL;
> >> > +       } else if (flags & MS_NOATIME) {
> >> > +               mnt_flags |= MNT_NOATIME;
> >> > +       } else {
> >> > +               mnt_flags |= MNT_RELATIME;
> >> > +       }
> >>
> >> I'm not sure reusing the MS_FLAGS is the right choice.  Why not export
> >> MNT_* to userspace?  That would get us a clean namespace without
> >> confusion with sb flags and no need to convert back and forth.
> >
> > Well, if you think about it as about two separated things -- VFS-flags
> > and FS-flags (and for example /proc/#/mountinfo already uses two
> > columns for the flags) than the question is why the API uses one
> > variable?
> >
> > Would be better to use two variables everywhere? (mostly for the
> > syscall).
> >
> > It would be nice to keep for example propagation flags only in
> > vfs_flags, or use MS_RDONLY according to context (for FS or for VFS)
> > without extra MS_BIND, etc.
> 
> MS_BIND will be gone in the new API.   The two separate columns in
> /proc/#/mountinfo are going to be two separate things on the new
> interface (one is writes to the fsfd provided by fsopen(2), the other
> in flags for fsmount(2)).

Ah, nice. 

> The question is how to call the mount flags
> (what you call vfs flags), "MS_RDONLY" or "MNT_RDONLY" on the uAPI.
> Either is probably fine, but I feel that "MNT_FOO" is better, because
> it's a relatively clean namespace concerned with mount flags and not
> polluted with all the scum that mount(2) collected.

Hmm.. for example libmount already uses MNT_ namespace in header
files for all macros. So, I wont be happy with MNT_ in userspace ;-(

I like clone, epoll, etc flags ... there is no any abbreviation and
the prefix follows syscall or API name (CLONE_xxx, EPOLLxxx), what
about MOUNT_FOO ?

    Karel

-- 
 Karel Zak  <kzak@xxxxxxxxxx>
 http://karelzak.blogspot.com



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux