Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1906471imm; Thu, 12 Jul 2018 09:42:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdD1T2dOzTv6uxMVmd2aRscQ/oLaT+rEzgHnfDseKgDVvHt4zbmjbwZOspnflrFb+1q0MyY X-Received: by 2002:a17:902:7202:: with SMTP id ba2-v6mr1034735plb.179.1531413735591; Thu, 12 Jul 2018 09:42:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531413735; cv=none; d=google.com; s=arc-20160816; b=kghxtRovWMLMYCiZQTu/tTkL0r/M35mP1kV5pUb3RPXtE8qRmyv4ZZe5bda0+73fMX XIDE2GDCESmgnBtWAnJigr6+B+susTfBEQTwSdNZb6YQuvEf8HpXzhwlM+1ZB2VIn3Qc FC3AcSEoJlUPvQ56igfUGDSOW7Kd+ylTV6cUqhe3x1CUWL9TGyHrHwlJfVzhPYGw3yV+ FQcSZA5QeFaUoGCI11mHmWoz8ek/b7Xv6xIuki2SufcepupOThYdGUYpLCb53wYkoYLZ aDNAjHqakRvadSkSPEJaYhYkN8zOEg4yTQ+cXQo3vvy4tCxKJTFoCx8zpB1lQ+E77g5M x1lg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=M6UhqBqdeMMDKiTn5bfp8Q/K/x8LDPZ71K+j5MKq8pw=; b=ZGWPjTjt6G5qpyW4aITvUApX3AurdZgaduey76oBb7AilDTRHl6Osvgusqm9OHOu+/ 3hPctS5eW2uGslXIZ4BXWcsLfeTYWXdwjIE0u3aWKFLq239ylqH1C9+sR+T9dQ2zxjQc r+CxRCdG+/VKOXylVY8K+wB2LaBw9j8J8UR0BhLd8wC3KTJlOL1AWTxgEltA6RFboRoK VIvxpN2PXqVctED5ve4Nrxnpc8HC9gO4jmwsd+yNqAm5C7TpQ17WUXSWvb2xDJl3w/qX O0iAfpaIGEsjWNjbDp30N9EUe3DNsaWkJ2oXGSXr9zO5L8cyiWBzT5SBOHAAuh97p9G5 Rgeg== 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 j193-v6si21123417pge.689.2018.07.12.09.42.00; Thu, 12 Jul 2018 09:42:15 -0700 (PDT) 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 S1727597AbeGLQve (ORCPT + 99 others); Thu, 12 Jul 2018 12:51:34 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:40704 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726925AbeGLQve (ORCPT ); Thu, 12 Jul 2018 12:51:34 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fdeeU-0001eK-Gi; Thu, 12 Jul 2018 16:41:10 +0000 Date: Thu, 12 Jul 2018 17:41:10 +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: <20180712164110.GX30522@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: > If you make a syscall that attaches a block device to an fscontext, you don’t need any of this. Heck, someone might actually *want* to grab a block device from a different namespace. Fuck, NO. The whole notion of "block device of filesystem" is fucking garbage. It's up to filesystem driver whether it uses any block devices. For backing store or otherwise. Single or multiple. Moreover, it's up to filesystem driver whether it cares if backing store is a block device, or mtd device, or... Repeat after me: syscall that attaches a block device to an fscontext makes as much sense as a syscall that attaches a charset name to the same. With a special syscall for attaching a timestamp granularity, and another for selecting GID semantics on subdirectory creation. Commit vs. write separation is one thing; fuckloads of special syscalls for passing vaguely defined classes of mount options (which device name *is*) is quite different.