Re: [PATCH 07/14] Implement fsopen() to prepare for a mount

From	David Howells <dhowells@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH 07/14] Implement fsopen() to prepare for a mount
Date	2017-05-11 16:40 +0200
Message-ID	<tFXq2-7wN-29@gated-at.bofh.it> (permalink)
References	<tFHXX-6iT-3@gated-at.bofh.it> <tFCvf-2Uw-1@gated-at.bofh.it> <tFCEV-2YC-1@gated-at.bofh.it> <tFHXX-6iT-3@gated-at.bofh.it>
Organization	Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903

Show all headers | View raw

Sargun Dhillon <sargun@sargun.me> wrote:

> Instead of string based configuration, does it perhaps make sense to
> pass in structured mount data? Something like:

I don't think it helps particularly.

> enum mount_command_id {
>     MOUNT_OPTION_STR,
>     MOUNT_SET_USER_NS
> };
> 
> struct mount_attr {
>    __u64 command_id;
>    union {
>        char option_str[4095];
>        char mount_source[PATH_MAX];

Why limit the option size to 4096?  I can see situations where it might be
necessary to hand in a bigger blob - giving cifs a Microsoft Kerberos PAC for
example.

>        struct {
>            __u32 user_ns_fd

There are more than just that namespace that could be relevant.

>        }
>    }
> }
> 
> It seems a lot less error prone to me.

Not really.  The only real difference is how one selects what action is
intended and how one determines the length.  write() has a length parameter.

David

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