[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVZQQCDA444R.KWA6OPEZRIBG@ftml.net>
Date: Wed, 04 Oct 2023 17:56:09 +0300
From: "Konstantin Shelekhin" <k.shelekhin@...l.net>
To: "Boqun Feng" <boqun.feng@...il.com>
Cc: "Alice Ryhl" <aliceryhl@...gle.com>, <alex.gaynor@...il.com>,
<benno.lossin@...ton.me>, <bjorn3_gh@...tonmail.com>,
<gary@...yguo.net>, <jiangshanlai@...il.com>,
<linux-kernel@...r.kernel.org>, <nmi@...aspace.dk>,
<ojeda@...nel.org>, <patches@...ts.linux.dev>,
<rust-for-linux@...r.kernel.org>, <tj@...nel.org>,
<wedsonaf@...il.com>, <yakoyoku@...il.com>
Subject: Re: [PATCH v4 7/7] rust: workqueue: add examples
> This is not a problem until nvmet actually uses/switches to Rust, right?
> ;-) We can certainly improve the API when a real user needs something.
> Or you know someone is already working on this?
Nope, not at this moment. I have an itch to experiment with Rust and
iSCSI, but that's my personal toy without any plans to at least propose
it to the subsystem maintainers yet.
> All of your suggestions make senses to me, but because we don't have
> many users right now, it's actually hard to determine a "best" API. I
> like what we have right now because it's explicit: people won't need to
> learn much about procedure macros to understand how it works, and it
> also provides better opportunities for people who's yet not familiar
> with Rust to give some reviews. So starting with something relatively
> simple and verbose may not be a bad idea ;-)
>
> Again, I like your idea, we need to explore that direction, but one
> dragon at a time ;-)
Oh yeah, completely understand :)
Powered by blists - more mailing lists