Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 07/14] Implement fsopen() to prepare for a mount | Date | Thu, 11 May 2017 15:30:34 +0100 |
| |
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
| |