From: Ming Lei <[email protected]>
To: Gabriel Krisman Bertazi <[email protected]>
Cc: [email protected], io-uring <[email protected]>,
Andreas Hindborg <[email protected]>,
Shinichiro Kawasaki <[email protected]>,
German Maglione <[email protected]>,
Stefano Garzarella <[email protected]>,
Joe Thornber <[email protected]>,
[email protected]
Subject: Re: Libublk-rs v0.1.0
Date: Tue, 15 Aug 2023 09:17:41 +0800 [thread overview]
Message-ID: <ZNrSNeCSg5qsOu61@fedora> (raw)
In-Reply-To: <[email protected]>
Hi Gabriel,
On Mon, Aug 14, 2023 at 02:23:14PM -0400, Gabriel Krisman Bertazi wrote:
> Ming Lei <[email protected]> writes:
>
> > Hello,
> >
> > Libublk-rs(Rust)[1][2] 0.1.0 is released.
>
> Hi Ming,
>
> Do you intend to effectively deprecate the code in ubdsrv in favor of
> libublk-rs or do you intend to keep the C library? I'm asking because
> I'm looking into how to enable ublk in distributions.
So far, there are users of C ubdsrv library, and both are maintained
and co-exist, so C library is still kept.
Thanks
Ming
>
> Thanks,
>
> >
> > The original idea is to use Rust to write ublk target for covering all
> > kinds of block queue limits/parameters combination easily when talking
> > with Andreas and Shinichiro about blktests in LSFMM/BPF 2023.
> >
> > Finally it is evolved into one generic library. Attributed to Rust's
> > some modern language features, libublk interfaces are pretty simple:
> >
> > - one closure(tgt_init) for user to customize device by providing all
> > kind of parameter
> >
> > - the other closure(io handling) for user to handling IO which is
> > completely io_uring CQE driven: a) IO command CQE from ublk driver,
> > b) target IO CQE originated from target io handling code, c) eventfd
> > CQE if IO is offloaded to other context
> >
> > With low level APIs, <50 LoC can build one ublk-null, and if high level
> > APIs are used, 30 LoC is enough.
> >
> > Performance is basically aligned with pure C ublk implementation[3].
> >
> > The library has been verified on null, ramdisk, loop and zoned target.
> > The plan is to support async/await in 0.2 or 0.3 so that libublk can
> > be used to build complicated target easily and efficiently.
> >
> > Thanks Andreas for reviewing and providing lots of good ideas for
> > improvement & cleanup. Thanks German Maglione for some suggestions, such
> > as eventfd support. Thanks Joe for providing excellent Rust programming
> > guide.
> >
> > Any feedback is welcome!
> >
> > [1] https://crates.io/crates/libublk
> > [2] https://github.com/ming1/libublk-rs
> > [3] https://github.com/osandov/blktests/blob/master/src/miniublk.c
> >
> > Thanks,
> > Ming
> >
>
> --
> Gabriel Krisman Bertazi
>
--
Ming
prev parent reply other threads:[~2023-08-15 1:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 2:56 Libublk-rs v0.1.0 Ming Lei
2023-08-14 18:23 ` Gabriel Krisman Bertazi
2023-08-15 1:17 ` Ming Lei [this message]
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=ZNrSNeCSg5qsOu61@fedora \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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