Message-ID: <bddea099-4468-4f96-2e06-2b207b608485@usi.ch>
Date: Fri, 18 Aug 2023 00:27:33 +0200
From: Davide Rovelli <roveld@....ch>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Michele Dalle Rive <dallerivemichele@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Greg KH <gregkh@...uxfoundation.org>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>,
 Davide Rovelli <davide.rovelli@....ch>, rust-for-linux@...r.kernel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [RFC PATCH 0/7] Rust Socket abstractions



On 8/17/23 19:14, Miguel Ojeda wrote:
> On Thu, Aug 17, 2023 at 4:53 PM Michele Dalle Rive
> <dallerivemichele@...il.com> wrote:
>>
>> The idea behind this patch is that, as of now, Rust is not a viable option for
>> any OOT module that requires even the highest-level network support.
>>
>> I am wondering whether the `net` subsystem is interested in reviewing, giving
>> feedback and eventually accepting code that is currently OOT-only.
> 
> It is unlikely kernel maintainers in general accept code intended for
> out-of-tree modules only.
> 
> To be clear, Rust for Linux's focus has never been out-of-tree
> modules. In fact, the whole effort since the beginning was about
> adding support for Rust in-tree, unlike other projects that e.g.
> linked `rustc`-built object files into an out-of-tree kernel module.
> 
> We do support out-of-tree modules, and have a sample of that, but that
> is just only to the degree that the kernel supports out-of-tree
> modules in general.
> 
> The abstractions that have been upstreamed so far are those that have
> (or should soon have) a user in-tree. Sometimes we have had to bend a
> bit the rules in order to split the dependency chain or make things
> easier, but abstractions (in general) cannot be upstreamed that do not
> have at least an expected and public user that is going upstream too.
> Here, by user, we generally mean an actual driver or useful component
> (rather than a sample).
> 
> If I understood correctly from Zulip, you cannot (right now) show your
> use case because it is confidential and therefore you cannot upstream
> it, so we will need another user (and, of course, that is a necessary
> but not sufficient condition for the code to be accepted).

Correct. I work with Michele, let me clarify. We are a research lab 
working on a low-jitter networking prototype implemented as an internal 
LKM (our last paper: 
https://www.usenix.org/system/files/atc21-jahnke.pdf). When trying to 
convert it to Rust, we noticed the lack of socket abstractions which 
Michele implemented. We then simply thought about sharing the 
abstractions with the community since they could fit a variety of 
use-cases - hence the patch.
We now understand the necessity of a concrete in-tree user, apologies 
for not realising this earlier: we are indeed new to patch process as 
you probably understood.
Our prototype might become available in the future but there's no clear 
path on when, this is our starting point.

> Of course, this does not preclude discussing about them or having a
> `rust-net` branch or sub-subsystem or similar. That could be quite
> useful so develop those users and to experiment. In fact, we are
> actively trying to onboard more people (and companies and other
> entities) to the Rust overall kernel effort, so please feel free to
> join us.

We will be more than happy to. In fact, I think the best place for this 
patch would be in a net branch/subsystem of the Rust for Linux repo. As 
mentioned in the Zulip chat, it's hard to provide a "full-fledged" patch 
in Rust at this point as many network building blocks are missing. The 
result is a number of bindings patches such as this one which do not 
match maintainers' interests but could be useful for other developers to 
eventually make a concrete user. It would have helped us significantly 
when starting this project, I think other researchers/developers share 
the same view.
If anyone is interested, we could add these patches to the mailing list 
with a low priority tag for feedback.

> By the way, I am a bit confused -- the patch seems to add an in-tree
> sample, not an out-of-tree one.

It is an in-tree sample, I guess Michele meant an "out-of-tree use-case" 
as in the sample doesn't introduce new core features in the kernel, just 
showcasing.

Powered by blists - more mailing lists