From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935670AbdEKOax (ORCPT ); Thu, 11 May 2017 10:30:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45936 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934420AbdEKOar (ORCPT ); Thu, 11 May 2017 10:30:47 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D7B94804F3 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dhowells@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D7B94804F3 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <149443309780.2378.6532276992468576087.stgit@warthog.procyon.org.uk> <149443316786.2378.6065648057770350840.stgit@warthog.procyon.org.uk> To: Sargun Dhillon Cc: dhowells@redhat.com, mszeredi@redhat.com, viro@zeniv.linux.org.uk, jlayton@redhat.com, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, LKML Subject: Re: [PATCH 07/14] Implement fsopen() to prepare for a mount MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6166.1494513034.1@warthog.procyon.org.uk> Date: Thu, 11 May 2017 15:30:34 +0100 Message-ID: <6167.1494513034@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 11 May 2017 14:30:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sargun Dhillon 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