[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz6Uaqag5qPcT2M3Q07-yc_6y2cAarfw7hjXEiQq4tTYw@mail.gmail.com>
Date: Thu, 12 Jul 2018 09:39:31 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: David Howells <dhowells@...hat.com>,
Andrew Lutomirski <luto@...nel.org>,
Linux API <linux-api@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for
superblock creation [ver #9]
On Thu, Jul 12, 2018 at 9:31 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> And seriously, ioctl? _That_ has a great track record...
I agree that a system call is likely saner. Especially since we'd have
one to _start_ this (ie "fsopen()") it would make sense to have the
one to finalize it.
> [1] one man's data is another man's commands, for starters. All networking
> protocols would fit your description. So would ANSI escape sequences ("move
> cursor to line 12 column 45" does sound like a command), so would writing
> postscript to printer, etc.
.. and all of that is just data to the kernel.
Yes, vt100 escape sequences etc _are_ commands, and boy have we had
bugs in that area. But there the excuse is "that's how the world is".
The thing is, "reality" is the ultimate argument. You can't argue with
cold hard facts.
But when designing a new interface that doesn't have that kind of
constraints, do it right.
> IME it's more about data structures that are not marshalled cleanly - that
> tends to go badly wrong. Again, see SG_IO for recent example...
SG_IO actually gets it right. It doesn't do async, but that's part of
the design (and a big part of why it's a lot simpler - the read-write
thing is actually broken too and just forces user space to basically
know SCSI).
Linus
Powered by blists - more mailing lists