lkml.org 
[lkml]   [2023]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 0/7] Rust Socket abstractions
From


On 8/17/23 19:14, Miguel Ojeda wrote:
> On Thu, Aug 17, 2023 at 4:53 PM Michele Dalle Rive
> <dallerivemichele@gmail.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.

\
 
 \ /
  Last update: 2023-08-18 00:28    [W:0.067 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site