Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1639218
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 06/14] VFS: Introduce a superblock configuration context |
| Date | 2017-05-11 09:30 +0200 |
| Message-ID | <tFQHT-3k5-11@gated-at.bofh.it> (permalink) |
| References | <tFCvf-2Uw-1@gated-at.bofh.it> <tFCEW-2YC-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, May 10, 2017 at 05:19:19PM +0100, David Howells wrote:
> + (*) struct mnt_namespace *mnt_ns
> +
> + This is a subset of the namespaces in use by the invoking process. This
> + retains a ref on each namespace. The subscribed namespaces may be
> + replaced by the filesystem to reflect other sources, such as the parent
> + mount superblock on an automount.
I don't think it's a good idea. No comments on userns stuff, but what's
the situation when you want it to play with the real namespace? Details,
please...
> + (*) int (*fill_super)(struct super_block *s, struct sb_config *sc);
> +
> + This is available to be used by things like mount_ns_mc() that are called
> + by ->mount() to transfer information/resources from the superblock configuration context to
> + the superblock.
Don't. This kind of stuff can bloody well be an explicit callback.
Methods of that kind are trouble - we had that sort of PITA quite a few
times, and it had always been a headache when we eventually had to kill them
off. Starting with ->read_inode(), if you remember that one...
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC][PATCH 00/14] VFS: Introduce superblock configuration context David Howells <dhowells@redhat.com> - 2017-05-10 18:20 +0200
[PATCH 01/14] Provide a function to create a NUL-terminated string from unterminated data David Howells <dhowells@redhat.com> - 2017-05-10 18:20 +0200
[PATCH 07/14] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
Re: [PATCH 07/14] Implement fsopen() to prepare for a mount Sargun Dhillon <sargun@sargun.me> - 2017-05-11 00:10 +0200
Re: [PATCH 07/14] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-11 16:40 +0200
Re: [PATCH 07/14] Implement fsopen() to prepare for a mount Jeff Layton <jlayton@redhat.com> - 2017-05-11 16:40 +0200
[PATCH 08/14] Implement fsmount() to effect a pre-configured mount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 11/14] proc: Add superblock config support to procfs David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 13/14] Support legacy filesystems David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 03/14] VFS: Make get_mnt_ns() return the namespace David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 05/14] VFS: Provide empty name qstr David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 02/14] Clean up whitespace in fs/namespace.c David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 10/14] procfs: Move proc_fill_super() to fs/proc/root.c David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 09/14] Sample program for driving fsopen/fsmount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
[PATCH 04/14] VFS: Make get_filesystem() return the affected filesystem David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
Re: [PATCH 06/14] VFS: Introduce a superblock configuration context Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-11 09:30 +0200
Re: [PATCH 14/14] Add commands to create or update a superblock Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-11 09:40 +0200
Re: [PATCH 14/14] Add commands to create or update a superblock Miklos Szeredi <mszeredi@redhat.com> - 2017-05-11 10:20 +0200
csiph-web