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

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

 



Sargun Dhillon <sargun@xxxxxxxxx> 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



[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