From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F847C476E8 for ; Thu, 12 Jul 2018 16:58:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A16420864 for ; Thu, 12 Jul 2018 16:58:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A16420864 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ZenIV.linux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732402AbeGLRIt (ORCPT ); Thu, 12 Jul 2018 13:08:49 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:41364 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726912AbeGLRIt (ORCPT ); Thu, 12 Jul 2018 13:08:49 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fdev7-00021Y-UU; Thu, 12 Jul 2018 16:58:21 +0000 Date: Thu, 12 Jul 2018 17:58:21 +0100 From: Al Viro To: Andy Lutomirski Cc: David Howells , Andy Lutomirski , Linux API , Linux FS Devel , Linus Torvalds , LKML , Jann Horn , tycho@tycho.ws Subject: Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9] Message-ID: <20180712165821.GY30522@ZenIV.linux.org.uk> References: <153126248868.14533.9751473662727327569.stgit@warthog.procyon.org.uk> <153126264966.14533.3388004240803696769.stgit@warthog.procyon.org.uk> <686E805C-81F3-43D0-A096-50C644C57EE3@amacapital.net> <22370.1531293761@warthog.procyon.org.uk> <7002.1531407244@warthog.procyon.org.uk> <338BC3C4-F3E7-48F0-A82E-2C7295B6640E@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <338BC3C4-F3E7-48F0-A82E-2C7295B6640E@amacapital.net> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 12, 2018 at 09:23:22AM -0700, Andy Lutomirski wrote: > As a straw man, I suggest: > > fsconfigure(contextfd, ADD_BLOCKDEV, dfd, path, flags); > > fsconfigure(contextfd, ADD_OPTION, 0, “foo=bar”, flags); Bollocks. First of all, block device *IS* a fucking option. Always had been. It's not even that it's passed as a separate argument for historical reasons - just look at NFS. That argument is a detached part of options, parsed (yes, *parsed*) by filesystem in question in whatever way it prefers. Look at the things like e.g. cramfs. That argument is interpreted as pathname of block device. Or that of mtd device. Or the magic string "mtd" followed by mtd number. What's more, filesystems can and do live on more than one device. Like e.g. btrfs. Or like something journalled with the journal on separate device. So you do *NOT* get away from the need to open stuff while doing mount - not unless you introduce arseloads of ADD_... shite in your scheme. And create a huge centralized pile of code dealing with it. ADD_NFS_IPV4_SERVER_AND_PATH, etc.? You can't avoid parsing stuff. It's one thing to argue at which *point* you prefer doing that, but it has to be done kernel-side. Format of filesystem options is fundamentally up to filesystem, whichever syscall you use.