[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0e91e3be-abbb-4bf7-be05-ba75c7522736@lunn.ch>
Date: Mon, 14 Aug 2023 22:23:17 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Michele Dalle Rive <dallerivemichele@...il.com>,
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, 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.
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
Powered by blists - more mailing lists