Linux Kernel Architecture

Chapter 12: Networks

The implementation for TCP follows a similar pattern but is made a little more complicated by the many

details and protocol oddities.

12.10.6 Sending Data

Userspace programs also have several alternative ways of sending data. They can use two network-

related system calls (sendtoandsend)orthewriteandwritevfunctions of the file layer. Because, once

again, the code in the kernel merges at a certain point, it is sufficient to examine the implementation of

the first of the above calls (in thesys_sendtoprocedure in the kernel sources). The associated code flow

diagram is shown in Figure 12-34.^34

sys_sendto

fget_light

sock_from_file

move_addr_to_kernel

sock_sendmsg sock->ops->sendmsg

Figure 12-34: Code flow diagram forsys_sendto.

fget_lightandsock_from_filefind the relevant socket by reference to the file descriptor. The data

to be sent are copied from userspace to kernel space usingmove_addr_to_kernelbeforesock_sendmsg

invokes the protocol-specific send routinesock->ops->sendmsg. This routine generates a packet in the

required format and forwards it to the lower layers.

12.11 Networking from within the Kernel

Not only userland applications have the desire and need to communicate with other hosts. The kernel

could likewise be required to communicate with other computers — without explicit requests from user-

land to do so. This is not only useful for oddities like the in-kernel web server that used to be included

with a number of releases. Network filesystems like CIFS or NCPFS depend on network communication

Networking from within the Kernel

This, however, does not yet fulfill all communication needs of the kernel. One more piece is missing:

communication between kernel components and communication between userland and kernel. The

The Netlink Mechanism

12.11.1 Communication Functions

First, let us turn our attention to the in-kernel networking API. The definitions are nearly identical to the

userland case:

(^34) The sources contain some code that has to deal with the case that__sock_sendmsgcan use an asynchronous request. I omit this
on purpose in the code flow diagram. If the request is not directly completed insock_sendmsg,thenwait_on_sync_kiocb
is called immediately aftersock_sendmsg, and the synchronous behavior is restored.