Re: [RFC PATCH 0/7] Rust Socket abstractions

[Michele Dalle Rive]

On Mon, 14 Aug 2023 at 23:36, Andrew Lunn <andrew@xxxxxxx> wrote:
>
> > > There is a long standing tradition in Linux, you don't get a new API
> > > merged without a user.
> >
> > Sorry for not being clear on that.
> >
> > These abstractions are meant to be used by modules: having them, modules
> > can start using the kernel network functionalities through a first, high level
> > interface.
> >
> > Since there is currently no network support in Rust, this patch series
> > represents a first step to provide access to networking to modules.
> > Sockets are just the highest layer of the network stack: the goal would be
> > to port structures deeper in the network stack, to give modules more
> > access to the network api. However, you need to start somewhere.
> >
> > >
> > > There is not too much use of in kernel sockets. Network file systems
> > > like NFS, and SMB are one. These need to be careful with memory usage,
> > > you could be busy writing blocks out because the system is low on
> > > memory and trying to free some up, and asking for more memory might
> > > not work.  Sending kernel log messages to a server. But that needs
> > > care because of the different contexts it can be used in. Without
> > > knowing what it will be used for, it is hard for us the point the
> > > special considerations which need to be made.
> > >
> > > So please also let us see the code using this API.
> > >
> > >         Andrew
> >
> > The lack of these abstractions was noticed in the context of a research
> > of the usability of Rust for the development of consensus algorithms using UDP.
>
> O.K, so what are the use cases for consensus algorithms using UDP
> within the kernel? Where is this code? Ideally you should post it for
> merging alongside the rust API to sockets its needs. We can then
> review both together, just as we would if somebody were submitting a
> new API in C along with its user.
>
>     Andrew

Hello Andrew,
in the last few days, I had the opportunity to discuss with some people from
the RustForLinux community.

I apologize for not being clear: the goal of these APIs was to give some
network support to, in particular, out-of-tree modules; they were not meant to
be used by a specific module that was planned to get upstreamed as well.
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.

Also, it would be interesting if you could provide us any module or
functionality you are planning to get in-tree which might use this interface;
it could be useful in order to understand the applicability of these
abstractions and find a concrete in-kernel use-case.

I included in the email a couple of sample OOT modules that showcase the
functionalities of the socket API; they will be attached as an actual patch if
there will be a v2.

Thank you for your time,
Michele