[net] Search for net subsystem rust abstractions in-progress

[net] Search for net subsystem rust abstractions in-progress

[Lane]

Hi,

I am following up on some advice given from the Rust forums where I am
trying to move some of my LKM's from C to Rust. These LKM's,basically
create new address family protocols using (for starters) structs and
functions like the following:

    struct net_proto_family;
    struct proto_ops;

    // Add a socket protocol handler
    err = sock_register(&proto_family);

These do not appear in the kernel crate. Per the
submitting-new-abstractions-and-modules section for contributions in
rust-for-linux, the second bullet point says to "check the mailing
list archive" because "part of the work may be already done or in the
process of being upstreamed", so I was hoping to see where things
stand and get advice.

I know the goals are not to duplicate or rewrite existing drivers, but
my modules have not been opened up yet and still going through heavy
development. I guess I am looking to know if there are proper API's or
abstractions for the net subsystem, otherwise, I may want to start
looking into contributing. It is also my understanding that we would
not want to be directly using any C bindings, rather, using a Rust
abstractions layer.

Thank you for any advice.

Re: [net] Search for net subsystem rust abstractions in-progress

[Andrew Lunn]

On Thu, Sep 24, 2026 at 09:48:13PM -0500, Lane wrote:
> Hi,
> 
> I am following up on some advice given from the Rust forums where I am
> trying to move some of my LKM's from C to Rust. These LKM's,basically
> create new address family protocols using (for starters) structs and
> functions like the following:
> 
>     struct net_proto_family;
>     struct proto_ops;
> 
>     // Add a socket protocol handler
>     err = sock_register(&proto_family);
> 
> These do not appear in the kernel crate. Per the
> submitting-new-abstractions-and-modules section for contributions in
> rust-for-linux, the second bullet point says to "check the mailing
> list archive" because "part of the work may be already done or in the
> process of being upstreamed", so I was hoping to see where things
> stand and get advice.

There have not been any contributions on adding new address families
from rust.

It is also somewhat unusual to add new address families. So before you
go too far, you might want to give a high level description of what
you are doing, just to make sure your architecture is correct.

	Andrew

Re: [net] Search for net subsystem rust abstractions in-progress

[Lane]

On 9/25/26 15:03, Andrew Lunn wrote:
> On Thu, Sep 24, 2026 at 09:48:13PM -0500, Lane wrote:
>> Hi,
>>
>> I am following up on some advice given from the Rust forums where I am
>> trying to move some of my LKM's from C to Rust. These LKM's,basically
>> create new address family protocols using (for starters) structs and
>> functions like the following:
>>
>>      struct net_proto_family;
>>      struct proto_ops;
>>
>>      // Add a socket protocol handler
>>      err = sock_register(&proto_family);
>>
>> These do not appear in the kernel crate. Per the
>> submitting-new-abstractions-and-modules section for contributions in
>> rust-for-linux, the second bullet point says to "check the mailing
>> list archive" because "part of the work may be already done or in the
>> process of being upstreamed", so I was hoping to see where things
>> stand and get advice.
> 
> There have not been any contributions on adding new address families
> from rust.
> 
> It is also somewhat unusual to add new address families. So before you
> go too far, you might want to give a high level description of what
> you are doing, just to make sure your architecture is correct.
> 
> 	Andrew

Thanks for the reply.

I understand the concerns of adding new address families. The high-level 
description is I've been working some Delay and Disruption Tolerant 
(DTN) LKM's as proof-of-concept that I would really like to rewrite in 
Rust. The Bundle Protocol (BP) LKM is dependent upon other LKM's for the 
supported convergence layers. These "DTN sockets" are accessible via the 
POSIX API, hence the new address family and it's integration with the 
POSIX interfaces.

Lane