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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
