All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <nmi@metaspace.dk>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-block@vger.kernel.org, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@suse.de>,
	Keith Busch <kbusch@kernel.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	Andreas Hindborg <a.hindborg@samsung.com>
Subject: [LSF/MM/BPF TOPIC] blk_mq rust bindings
Date: Thu, 02 Mar 2023 20:37:04 +0100	[thread overview]
Message-ID: <87y1ofj5tt.fsf@metaspace.dk> (raw)

Hi,

I would like to suggest a session on the application of Rust in blk-mq drivers.

At LPC I presented work on an NVMe driver for Linux written in Rust. The purpose
of the driver is to help shape Rust abstractions of kernel APIs and to verify
feasibility of safe Rust for high performance drivers. One suggestion from the
audience was to look into null_blk, as this would eliminate hardware related
overhead in benchmark results.

I did an analysis of all the commits in the null_blk driver (currently 256
exluding merge commits). 27% (68) of these commits are bug fixes. Out of these
27%, 41% (28) are fixes for memory safety issues. These are issues that would be
avoided in a Rust based implementation.

I am working on an implementation of a null_blk in Rust. I plan to send a patch
set before LSF to serve as a base of discussion.

Suggested discussion points:
============================

 - Feasibility in terms of performance for Rust based Linux kernel drivers
 - Importance of memory safety in the Linux Kernel and how Rust can help
 - How to maintain Rust bindings for blk-mq

Best regards,
Andreas Hindborg

                 reply	other threads:[~2023-03-02 19:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=87y1ofj5tt.fsf@metaspace.dk \
    --to=nmi@metaspace.dk \
    --cc=Damien.LeMoal@wdc.com \
    --cc=a.hindborg@samsung.com \
    --cc=axboe@fb.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.