Messages in this thread |  | | Subject | Re: [PATCH 07/14] Implement fsopen() to prepare for a mount | From | Jeff Layton <> | Date | Thu, 11 May 2017 10:35:11 -0400 |
| |
On Thu, 2017-05-11 at 15:30 +0100, David Howells wrote: > 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. >
Agreed. I like the text based configuration better.
It also has another advantage: It's easy to strace the program and see what it's doing. With an opaque blob, we'd need to teach strace how to format the thing to be able to view it.
-- Jeff Layton <jlayton@redhat.com>
|  |