From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karel Zak Subject: Re: User-visible context-mount API Date: Wed, 17 Jan 2018 11:43:35 +0100 Message-ID: <20180117104335.m3oo3ee2xmercau3@ws.net.home> References: <28167.1516032442@warthog.procyon.org.uk> <22576.1516097412@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <22576.1516097412-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Howells Cc: Miklos Szeredi , viro , Jeff Layton , "Eric W. Biederman" , linux-fsdevel , Linux API List-Id: linux-api@vger.kernel.org On Tue, Jan 16, 2018 at 10:10:12AM +0000, David Howells wrote: > Inside the kernel the MS_* flags appear to belong to a number of fundamentally > different classes: Good point, but I'm not sure about your terminology -- for example "topology" sounds strange if we use "propagation" for years. > (1) Things like MS_SILENT and MS_REMOUNT which affect the behaviour of the > mount process, but aren't persistent beyond that. mount-operation flags (now including MS_BIND too) > (2) Inter-namespace topology management, controlling how mounts are shared > and duplicated between namespaces. propagation flags > (3) Restrictions on accesses through a particular mountpoint, eg. MS_NODEV, > MS_NOEXEC. VFS flags (now including MS_BIND|MS_REMOUNT|MS_RDONLY too) > (4) Instructions to a filesystem on how a superblock is to behave. FS flags > I think the classes are fundamentally different - and we've already separated > (4) from the others inside the kernel. However, I've no great objection to > keeping (2) and (3) together in the same mask. It just sounds cleaner to > separate them. I agree. Karel -- Karel Zak http://karelzak.blogspot.com