Repository navigation
Socket abstraction support #1022
Description
Goal and requirements
The main goal of this issue is to track the development of a generic Rust Socket interface binded to the C struct socket.
The functionalities I am planning to add to the Rust interface are:
- Socket generic structure and, possibly, specific Tcp and Udp wrappers.
- Basic socket functionalities
- Socket creation (
sock_create,sock_create_kern,sock_create_lite) - Bind, listen and accept (
kernel_bind,kernel_listen,kernel_accept) - Information retrieval (
kernel_getsockname,kernel_getpeername) - Release (
sock_shutdown,sock_release)
- Socket creation (
- Generic addresses handling
- Enum representation of the
sockaddrstructs (sockaddr_in,sockaddr_in6, etc) - Bindings for the internet address structures (
in_addr,in6_addr) - Binding for the generic C
struct sockaddr_storage.
- Enum representation of the
Dependencies
The following graph shows the interaction between the different C entities involved in the socket abstraction.
- Green entities will be implemented in the Rust interface.
- Purple entities will be implemented partially, at least in the beginning, starting with the most used ones (i.e.
IPPROTO_TCPandIPPROTO_UDPwill be added beforeIPPROTO_ETHERNET) - Yellow entities will not be implemented: these entities are highly complex and their implementation is not strictly required to accomplish the goal, which is to provide basic socket functionalities.
Implementation
A possible implementation UML could be as follows:
There are a few considerations on that:
-
Receive and Send operations behave differently based on the type of socket: UDP (and other connection-less protocols) write in
msghdr->msg_namethe address of the sender of the packet; other protocols, like TCP, do not do it, as they are connection-oriented. I tried to keep it as generic as possible, binding a struct to the Cstruct msghdr. -
Tcp and Udp wrappers could give an abstraction layer advantage: since they behave differently, their send and receive methods could use the generic socket one, but have a different return type; for example:
Development
The socket implementation would happen inside the rust/kernel/net/ folder. It is probably best to put the widely used entities, like IPPROTO_* and AddressFamily in a separate module, in order to keep a fine-grained logical division.
I will be working on the implementation of these functionalities on this this branch.
Contributions
The work on this interface is based on:
- The original net.rs module in the
rustbranch - The net bindings written by @fujita in their net module
Any comment or suggestion is highly appreciated :)



Activity
fujita commentedon Jul 21, 2023
You can use connect() for an UDP socket too. Then you can do recv/send in the same way as TCP. So I don't think that
their send and receive methods could use the generic socket one, but have a different return typeis an appropriate approach.GuilhermeGiacomoSimoes commentedon Jan 11, 2025
@micheledallerive
will you init make this socket abstraction support, or I can make this ?
tgross35 commentedon Jan 11, 2025
Michele has already done a lot of the work, it is available at #1066. There is a handful of feedback that needs to be addressed, some of that could probably be picked up.
Do you have an int-tree usecase?