[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACETy0=V9B8UOCi+BKfyrX06ca=WvC0Gvo_ouR=DjX=_-jhAwg@mail.gmail.com>
Date: Mon, 14 Aug 2023 23:06:34 +0200
From: Michele Dalle Rive <dallerivemichele@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: 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 Mon, 14 Aug 2023 at 22:23, Andrew Lunn <andrew@...n.ch> wrote:
>
> On Mon, Aug 14, 2023 at 05:25:49PM +0200, Greg KH wrote:
> > On Mon, Aug 14, 2023 at 11:22:55AM +0200, Michele Dalle Rive wrote:
> > > This patch series is intended to create Rust abstractions for Sockets
> > > and other fundamental network entities.
> > >
> > > Specifically, it was added:
> > > - Ip address and Socket address wrappers (for `in_addr`, `in6_addr`,
> > > `sockaddr_in`, `sockaddr_in6`, `sockaddr_storage`).
> > > - Socket wrapper.
> > > - Socket flags and options enums.
> > > - TCP and UDP specific abstractions over the Rust Socket structure.
> > >
> > > This series is a RFC because I would appreciate some feedback about:
> > > - The structure of the module: is the division of the files and modules
> > > appropriate or should it be more or less fine-grained?
> > > Also, should the `net` module export all the structures of its
> > > submodules? I noticed that it is done in the standard library.
> > > - Whether the documentation is comprehensive enough.
> > > - A few other specific questions, written in the individual patches.
> > >
> > > I would greatly appreciate any kind of feedback or opinion.
> > > I am pretty new to the patch/mailing list world, so please point out any
> > > mistake I might make.
> >
> > The best feedback is "who will use these new interfaces?" Without that,
> > it's really hard to review a patchset as it's difficult to see how the
> > bindings will be used, right?
>
> 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.
Any kind of kernel module requiring network support can take advantage
of these socket abstractions, from a tcp echo server to any kind of complex
networking kernel module.
I could add an example kernel module in `samples/rust` showing an example
of usage of these APIs.
Thank you for your time,
Michele
Powered by blists - more mailing lists