From: Bart Van Assche <bvanassche@acm.org>
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: Wed, 2 Feb 2022 12:36:12 -0800 [thread overview]
Message-ID: <4de2c701-6a83-cf7f-69ba-36a921997180@acm.org> (raw)
In-Reply-To: <20220201013329.ofxhm4qingvddqhu@garbanzo>
On 1/31/22 17:33, 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].
> 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.
Do we need a new netlink family for this purpose? The RDMA subsystem
uses netlink since considerable time for configuration purposes instead
of ioctls, sysfs or configfs. The user space tool 'rdma' supports that
interface. That tool is used by e.g. blktests to configure the soft-RoCE
and soft-iWARP interfaces.
See also rdma(8), available at e.g.
https://man7.org/linux/man-pages/man8/rdma.8.html.
Bart.
next prev parent reply other threads:[~2022-02-02 20:36 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
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 [this message]
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=4de2c701-6a83-cf7f-69ba-36a921997180@acm.org \
--to=bvanassche@acm.org \
--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 NNTP newsgroup(s).