lkml.org 
[lkml]   [2017]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 07/14] Implement fsopen() to prepare for a mount
Date
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

\
 
 \ /
  Last update: 2017-05-11 16:32    [W:0.113 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site