From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Luis Chamberlain <mcgrof@kernel.org>, lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
Steven Whitehouse <swhiteho@redhat.com>,
Steve French <stfrench@microsoft.com>,
Samuel Cabrero <scabrero@suse.de>,
David Teigland <teigland@redhat.com>,
Namjae Jeon <namjae.jeon@samsung.com>,
Josef Bacik <josef@toxicpanda.com>
Subject: Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?
Date: Tue, 01 Feb 2022 07:56:19 -0500 [thread overview]
Message-ID: <f4f86a3e1ab20a1d7d32c7f5ae74419c8d780e82.camel@HansenPartnership.com> (raw)
In-Reply-To: <20220201013329.ofxhm4qingvddqhu@garbanzo>
On Mon, 2022-01-31 at 17:33 -0800, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].
And many systems besides ... we're also adding new ioctls for things
like containers.
However, could I just ask why you object to ioctls? I agree, like any
drug, overuse leads to huge problems. However, there are medicinal use
cases where they actually save a huge amount of pain. So I think as
long as we're careful we can still continue using them.
What is the issue? Just the non-introspectability of the data from the
perspective of tools like seccomp?
> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it. *If* we do want this I think we just
> not only need to commit to do this, but also provide a target. LSFMM
> seems like a good place to do this.
It's not just netlink. We have a huge plethora of interfaces claiming
to replace the need for ioctl as a means for exchanging information
between a multiplexor and an in-kernel set of receivers. The latest
one I noticed would be fsconfig, although that is filesystem specific
(but could be made more generic). And, of course, configfs was
supposed to be another generic but introspectable configuration
exchange system. We're quite good at coming up with ioctl replacement,
however when we do they don't seem to be as durable. I think we should
really examine what we think the problem is in detail before even
starting to propose a solution.
James
next prev parent reply other threads:[~2022-02-01 12:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 1:33 [LSF/MM/BPF TOPIC] are we going to use ioctls forever? Luis Chamberlain
2022-02-01 2:14 ` Matthew Wilcox
2022-02-03 12:25 ` Jan Kara
2022-02-28 21:46 ` Luis Chamberlain
2022-03-01 7:47 ` Arnd Bergmann
2022-03-01 16:23 ` Luis Chamberlain
2022-02-01 12:56 ` James Bottomley [this message]
2022-02-28 22:00 ` Luis Chamberlain
2022-02-01 13:20 ` Christian Brauner
2022-02-28 22:02 ` Luis Chamberlain
2022-02-02 10:39 ` Steven Whitehouse
2022-02-28 22:13 ` Luis Chamberlain
2022-02-02 20:36 ` Bart Van Assche
2022-02-28 22:07 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4f86a3e1ab20a1d7d32c7f5ae74419c8d780e82.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mcgrof@kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=scabrero@suse.de \
--cc=stfrench@microsoft.com \
--cc=swhiteho@redhat.com \
--cc=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).