Socket abstraction support

[micheledallerive]

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)
• Generic addresses handling
  • Enum representation of the sockaddr structs (sockaddr_in, sockaddr_in6, etc)
  • Bindings for the internet address structures (in_addr, in6_addr)
  • Binding for the generic C struct sockaddr_storage.

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_TCP and IPPROTO_UDP will be added before IPPROTO_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_name the 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 C struct 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 rust branch
• The net bindings written by @fujita in their net module

Any comment or suggestion is highly appreciated :)

[fujita]

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 type is an appropriate approach.

[GuilhermeGiacomoSimoes]

@micheledallerive
will you init make this socket abstraction support, or I can make this ?

[tgross35]

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?