[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180712164110.GX30522@ZenIV.linux.org.uk>
Date: Thu, 12 Jul 2018 17:41:10 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Andy Lutomirski <luto@...capital.net>
Cc: David Howells <dhowells@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Linux API <linux-api@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Jann Horn <jannh@...gle.com>, tycho@...ho.ws
Subject: Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for
superblock creation [ver #9]
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.
Powered by blists - more mailing lists