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 changes in this patch series are based on top of the latest commit
of `rust-next` in the Rust git tree: 
19cd7b5d229c ("btf, scripts: rust: drop is_rust_module.sh")

Michele Dalle Rive (7):
  rust: net: add net module files and shared enums.
  rust: net: add ip and socket address bindings.
  rust: net: add socket-related flags and flagset.
  rust: net: add socket wrapper.
  rust: net: implement socket options API.
  rust: net: add socket TCP wrappers.
  rust: net: add socket UDP wrappers.

 rust/bindings/bindings_helper.h |    3 +
 rust/kernel/lib.rs              |    2 +
 rust/kernel/net.rs              |  185 +++++
 rust/kernel/net/addr.rs         | 1215 ++++++++++++++++++++++++++++++
 rust/kernel/net/ip.rs           |   73 ++
 rust/kernel/net/socket.rs       |  641 ++++++++++++++++
 rust/kernel/net/socket/flags.rs |  467 ++++++++++++
 rust/kernel/net/socket/opts.rs  | 1222 +++++++++++++++++++++++++++++++
 rust/kernel/net/tcp.rs          |  252 +++++++
 rust/kernel/net/udp.rs          |  182 +++++
 10 files changed, 4242 insertions(+)
 create mode 100644 rust/kernel/net.rs
 create mode 100644 rust/kernel/net/addr.rs
 create mode 100644 rust/kernel/net/ip.rs
 create mode 100644 rust/kernel/net/socket.rs
 create mode 100644 rust/kernel/net/socket/flags.rs
 create mode 100644 rust/kernel/net/socket/opts.rs
 create mode 100644 rust/kernel/net/tcp.rs
 create mode 100644 rust/kernel/net/udp.rs

-- 
2.41.0

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?

thanks,

greg k-h

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

On Mon, 14 Aug 2023 at 22:23, Andrew Lunn <andrew@lunn.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

> > 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

On Mon, 14 Aug 2023 at 23:36, Andrew Lunn <andrew@lunn.ch> 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


From 4c966f6ff3acd3b7c27f7a558648722b227d45a7 Mon Sep 17 00:00:00 2001
From: Michele Dalle Rive <dallerivemichele@gmail.com>
Date: Thu, 17 Aug 2023 15:51:47 +0200
Subject: [PATCH] rust: net: add OOT sample modules.

Add two sample modules that showcase some functionalities of the Rust
socket API.

Signed-off-by: Michele Dalle Rive <dallerivemichele@gmail.com>
---
 samples/rust/rust_socket.rs     | 45 +++++++++++++++++++++++++++++++++
 samples/rust/rust_tcp_server.rs | 34 +++++++++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 samples/rust/rust_socket.rs
 create mode 100644 samples/rust/rust_tcp_server.rs

diff --git a/samples/rust/rust_socket.rs b/samples/rust/rust_socket.rs
new file mode 100644
index 000000000000..fc1ed8536e57
--- /dev/null
+++ b/samples/rust/rust_socket.rs
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust minimal sample.
+
+use core::str::FromStr;
+use kernel::prelude::*;
+use kernel::net::socket::*;
+use kernel::net::ip::IpProtocol;
+use kernel::net::addr::{SocketAddr};
+use kernel::net::AddressFamily;
+use kernel::flag_set;
+
+module! {
+    type: RustSocket,
+    name: "rust_socket",
+    author: "Rust for Linux Contributors",
+    description: "Rust sockets support sample",
+    license: "GPL",
+}
+
+struct RustSocket {}
+
+impl kernel::Module for RustSocket {
+    fn init(_module: &'static ThisModule) -> Result<Self> {
+        let sock = Socket::new(AddressFamily::Inet,
SockType::Datagram, IpProtocol::Udp)?;
+        let addr = "0.0.0.0:8000";
+        sock.bind(SocketAddr::from_str(addr)?)?;
+
+        sock.set_option::<opts::sock::ReuseAddr>(true)?;
+
+        assert_eq!(sock.sockname()?, SocketAddr::from_str(addr)?);
+
+        let mut buf = [0; 1024];
+        while let Ok((bytes, msghdr)) = sock.receive_msg(&mut buf,
flag_set!()) {
+            if bytes == 0 {
+                break;
+            }
+            pr_info!("Received {} bytes from {}", bytes,
msghdr.address().unwrap());
+            if msghdr.flags().contains(flags::MessageFlag::Trunc) {
+                pr_info!("The message was truncated");
+            }
+        }
+        Ok(Self{})
+    }
+}
\ No newline at end of file
diff --git a/samples/rust/rust_tcp_server.rs b/samples/rust/rust_tcp_server.rs
new file mode 100644
index 000000000000..987c4c752d2b
--- /dev/null
+++ b/samples/rust/rust_tcp_server.rs
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust echo server sample.
+
+use core::str::FromStr;
+use kernel::prelude::*;
+use kernel::net::tcp::TcpListener;
+use kernel::net::addr::SocketAddr;
+use kernel::flag_set;
+
+module! {
+    type: RustTcpServer,
+    name: "rust_tcp_server",
+    author: "Rust for Linux Contributors",
+    license: "GPL",
+}
+
+struct RustTcpServer {}
+
+impl kernel::Module for RustTcpServer {
+    fn init(_module: &'static ThisModule) -> Result<Self> {
+        let listener =
TcpListener::new(SocketAddr::from_str("0.0.0.0:8000")?)?;
+        while let Ok(stream) = listener.accept() {
+            let mut buf = [0; 1024];
+            while let Ok(size) = stream.receive(&mut buf, flag_set!()) {
+                if size == 0 {
+                    break;
+                }
+                stream.send(&buf[..size], flag_set!())?;
+            }
+        }
+        Ok(Self {})
+    }
+}
-- 
2.41.0

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).

> 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 think it is easier if it is the other way around :) That is, the
people/companies that already have a use case for the abstractions
should come forward and publish them so that the abstractions are
justified.

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.

> 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.

The sample should not be an out-of-tree module, it should be an
in-tree one. However, for upstreaming, just a sample is likely to not
be enough for most kernel maintainers, as mentioned above.

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

Cheers,
Miguel

> If I understood correctly from Zulip, you cannot (right now) show your
> use case because it is confidential and therefore you cannot upstream
> it

Is there a clear path for it to become public and mergable?

There is also a general trend that code developed behind closed doors
needs a complete re-write when made public and reviewed by mainline
developers. And that rewrite could involve the APIs to other
subsystems, like sockets. So any API you define now with a 'toy' in
kernel user, could in fact be totally useless by the time your real
target gets merged.

As Jon pointed out, we kernel maintainers need to help people coming
from a different background. Within the community it is well known
that internal APIs are unstable. Any developer can change any API, and
all its in kernel users if there is a need to do so. This makes
maintaining out of tree modules hard. There are a number of 'vendor
crap' drivers which do do this, with lots of ugly code to work around
differences between kernel versions. To some extent, that works
because the C APIs are not that volatile. My guess is, the Rust APIs
are going to be a lot more volatile for a number of years while
developers figure out what good APIs look like, and rework them again
and again, and again. Anybody trying to maintain an out of tree rust
module is going to be in a world of pain. In tree however, benefits
from the fast that any developer who wants to change an API needs to
also change all users...

       Andrew

On Thu, 17 Aug 2023 19:14:19 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> 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).

I thought Rust symbols were all export symbol GPL.
And therefore any Rust module using these must also be GPL.

On Thu, Aug 17, 2023 at 8:38 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> I thought Rust symbols were all export symbol GPL.
> And therefore any Rust module using these must also be GPL.

They may be not distributing it just yet, e.g. it may be in
development as part of an academic paper, but they may be able to
publish later.

Cheers,
Miguel

On Thu, 17 Aug 2023 16:53:03 +0200 Michele Dalle Rive wrote:
> 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.

This is a bit concerning. You can white out Rust in that and plonk in
some corporate backed project people tried to cram into the kernel
without understanding the community aspects. I'm not saying it's 
the same but the tone reads the same.

"The `net` subsystem" have given "the RustForLinux community" clear
guidance on what a good integration starting point is. And now someone
else from Rust comes in and talk about supporting OOT modules.

I thought the Rust was just shaking up the languages we use, not the
fundamentals on how this project operates :|

Jakub Kicinski <kuba@kernel.org> writes:

> I thought the Rust was just shaking up the languages we use, not the
> fundamentals on how this project operates :|

I don't think this little episode has anything to do with Rust, really;
certainly we've had no shortage of companies wanting support for
out-of-tree modules written in C over the years.

Instead, this is just the sort of thing you see when people who are new
to our community learn - the hard way, sometimes - how kernel
development works.  Rust seems likely to bring in a fair number of new
developers, which is great, but we're going to have to help them learn
their way around.

Thanks,

jon

On Thu, Aug 17, 2023 at 5:48 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> This is a bit concerning. You can white out Rust in that and plonk in
> some corporate backed project people tried to cram into the kernel
> without understanding the community aspects. I'm not saying it's
> the same but the tone reads the same.
>
> "The `net` subsystem" have given "the RustForLinux community" clear
> guidance on what a good integration starting point is. And now someone
> else from Rust comes in and talk about supporting OOT modules.
>
> I thought the Rust was just shaking up the languages we use, not the
> fundamentals on how this project operates :|

I am not sure what you mean by "from Rust", but to clarify, Rust for
Linux's focus has never been out-of-tree modules.

In fact, the whole effort since the beginning has been 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 have
also been advising interested parties/newcomers on kernel guidelines
etc.

And, of course, the Rust subsystem is definitely not trying to change
any fundamentals. If it looks like so, then please note that, like any
other subsystem, we may have patch submitters coming from different
backgrounds and not part of the Rust subsystem team.

Cheers,
Miguel

On Thu, Aug 17, 2023 at 08:48:48AM -0700, Jakub Kicinski wrote:
> On Thu, 17 Aug 2023 16:53:03 +0200 Michele Dalle Rive wrote:
> > 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.
> 
> This is a bit concerning. You can white out Rust in that and plonk in
> some corporate backed project people tried to cram into the kernel
> without understanding the community aspects. I'm not saying it's 
> the same but the tone reads the same.
> 
> "The `net` subsystem" have given "the RustForLinux community" clear
> guidance on what a good integration starting point is. And now someone
> else from Rust comes in and talk about supporting OOT modules.
> 
> I thought the Rust was just shaking up the languages we use, not the
> fundamentals on how this project operates :|

I want to make it clear that Rust is not a way to get anyone a special
pass for OOT support. That's never the intention of people in RUST
maintainer entries.

Here Michele did a good job on honestly sharing the context of the work. 

After the patchset sent, there was a discusion in Rust-for-Linux zulip
about why a in-tree user is needed for review (and merge), and how
people who are interested in networking could work with netdev on
finding useful in-tree users and correct abstraction/bindings. I
personally didn't sense anyone trying to undermining the Linux kernel
development.

Please understand that "the RustForLinux community" cannot control
everyone's mind to make them aware of Linux kernel's contribution
policy, but surely there is no execuse not reading:

	https://docs.kernel.org/process/development-process.html	

before contribution.

Regards,
Boqun

> I am wondering whether the `net` subsystem is interested in reviewing, giving
> feedback and eventually accepting code that is currently OOT-only.

netdev, and the linux kernel in general, has no interest in code to
support out of tree modules. It adds maintenance cost for no gain.
 
> 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.

You need real code which does something useful for the community. Your
problem is, there is little use of sockets inside the kernel. I did
list a few examples in my first reply. Network file systems, logging
kernel messages to a remote server. I thought of one more afterwards,
there is dhcp client code used for NFS root, which could make use of
raw sockets.

However, you have the problem you cannot just rewrite this existing
code in Rust because it is core code and needs to work on all
architectures. And my understanding is, there are currently not Rust
compilers for all architectures.

What you can however do is implement something new, which the kernel
does not have. If it never existed, it is hard to complain it is only
available for a restricted number of architectures. So maybe look
through the RFCs and IETF documents and see if you can find something
which is both useful, and makes sense to be implemented in the kernel.

      Andrew