Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp55061ybl; Thu, 12 Dec 2019 13:59:03 -0800 (PST) X-Google-Smtp-Source: APXvYqy6nD2RNTtZBQNpJ6aRjEcDOupbMCo5tIWiokBop6gArTWKeliRQPw5tvmbkvvGsuZf0LTC X-Received: by 2002:a9d:7a8f:: with SMTP id l15mr10108686otn.109.1576187943900; Thu, 12 Dec 2019 13:59:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576187943; cv=none; d=google.com; s=arc-20160816; b=fmlu8qTaafIjyf2rcPDftFKEue/1m+ydJmLUjj/w4aUN15m7WHUwrco1WF3kMDqxO5 zXGgHT/Smb4TIPse2XB8PaIspPy1NFwecuNcPtBacr0VdI0CFGdYxFopWrXcoBHQY+5t eRuJul5uvuMDiKVH9BB5o/TqbCJDXl2qbjntUgGro7DG1zpLEsKgTxyavERSWWHt2NBU aGlikh0wNJ0EgrmfJAUzy3TYPxL1KHBPb/+rlAUDo3Qnh/g+Vl/m4ykJa7oUOv1QzgyC SrUc/GDN2kbdEHwfOxvLxv4ZTPlwrZKooCVM8wzBkWqhW8X3uzt53a36sEUAzP+6JeZL 3bbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=T95mhDNr6rSSgmlMMaxc/S9cJw1opfk2lAhz0ypnjBA=; b=hsWhCIRV/6CCDR/oo145kzLxpwM/1E0whh/fSqM5tqf9hIfqOOWAXh9Q0vewsIQMCK ImuQcKsTGhAZtvfbPVM4IAHnrQEzhni6YsBUv68OGNNDYukVSF9uxGfVMgvLsuUE/i/N r2cHJU8TBIstWSlQOATCVvk/fXtctBEGtp/N3boK81oCjsXnGCWuNSxBRDoWmJofGe+w fjucGUjpEPXoLWZNvb+S0blGA1G3wbImlYY2JIWGqw8Ll54KU6bBPTWgwpfGkQ/9PFxX QjE5ISzyEl9yt8Nd2yvtgexQhCExdBfBaj0gR7U4icaXYgcSKq5rh/eUkMG+iIGE+IAJ Ng/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c195si4060997oib.266.2019.12.12.13.58.51; Thu, 12 Dec 2019 13:59:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730947AbfLLVr1 (ORCPT + 99 others); Thu, 12 Dec 2019 16:47:27 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:54628 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730831AbfLLVr0 (ORCPT ); Thu, 12 Dec 2019 16:47:26 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifWIu-0001IZ-3M; Thu, 12 Dec 2019 21:47:24 +0000 Date: Thu, 12 Dec 2019 21:47:24 +0000 From: Al Viro To: Laura Abbott Cc: David Howells , Jeremi Piotrowski , Linux FS Devel , Linus Torvalds , Phillip Lougher , linux-kernel@vger.kernel.org, Ilya Dryomov Subject: Re: [PATCH] vfs: Handle file systems without ->parse_params better Message-ID: <20191212214724.GL4203@ZenIV.linux.org.uk> References: <20191212213604.19525-1-labbott@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191212213604.19525-1-labbott@redhat.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 12, 2019 at 04:36:04PM -0500, Laura Abbott wrote: > @@ -141,14 +191,19 @@ int vfs_parse_fs_param(struct fs_context *fc, struct fs_parameter *param) > */ > return ret; > > - if (fc->ops->parse_param) { > - ret = fc->ops->parse_param(fc, param); > - if (ret != -ENOPARAM) > - return ret; > - } > + parse_param = fc->ops->parse_param; > + if (!parse_param) > + parse_param = fs_generic_parse_param; > + > + ret = parse_param(fc, param); > + if (ret != -ENOPARAM) > + return ret; > > - /* If the filesystem doesn't take any arguments, give it the > - * default handling of source. > + /* > + * File systems may have a ->parse_param function but rely on > + * the top level to parse the source function. File systems > + * may have their own source parsing though so this needs > + * to come after the call to parse_param above. > */ > if (strcmp(param->key, "source") == 0) { > if (param->type != fs_value_is_string) > -- > 2.21.0 No. Please, get rid of the boilerplate. About 80% of that thing is an absolutely pointless dance around "but we need that to call fs_parse()". We do *NOT* need to call fs_parse() here. We do not need a struct fs_parameter_description instance. We do not need struct fs_parameter_spec instances. We do not need a magical global constant. And I'm not entirely convinced that we need to make fs_generic_parse_param() default - filesystems that want this behaviour can easily ask for it. A sane default is to reject any bogus options. I would call it ignore_unknowns_parse_param(), while we are at it.