From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757289AbdJKIyW (ORCPT ); Wed, 11 Oct 2017 04:54:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33530 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756707AbdJKIyT (ORCPT ); Wed, 11 Oct 2017 04:54:19 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C395D129B Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=kzak@redhat.com Date: Wed, 11 Oct 2017 10:54:13 +0200 From: Karel Zak To: Miklos Szeredi Cc: David Howells , viro , linux-fsdevel , linux-nfs@vger.kernel.org, lkml , Jeff Layton Subject: Re: [PATCH 06/14] VFS: Implement fsmount() to effect a pre-configured mount [ver #6] Message-ID: <20171011085413.gexlklmojlve5imd@ws.net.home> References: <150730494491.6182.5139368907374172391.stgit@warthog.procyon.org.uk> <150730499269.6182.8121149524716523148.stgit@warthog.procyon.org.uk> <20171010095107.5lzkjibyrxbwfpvp@ws.net.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912-66-504cd9 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 11 Oct 2017 08:54:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 10, 2017 at 03:38:21PM +0200, Miklos Szeredi wrote: > On Tue, Oct 10, 2017 at 11:51 AM, Karel Zak 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 http://karelzak.blogspot.com