An executing program that needs to use a protocol within the Linux kernel goes through a number of different layers before reaching its final processing stage. The following description applies to the TCP/IP stack.
On the user side, a program executes a system socket command, such as socket(), bind() or connect(). This is passed into the kernel side through the sys_socketcall() function located in the /usr/src/linux/net/socket.c file. This function takes the arguments and selects the kernel side equivalent of the function the user called. For example, if the user called the socket() function to create a new socket, the sys_socketcall() will pass control onto the sys_socket() function.
The sys_socket() function is responsible for creating memory for the new socket structure and initialising some of the variables. Depending on the family of the socket, it assigns the ops pointer to the relevant proto_ops structure. The proto_ops structure contains function pointers to the socket family equivalent of the various functions needed by a socket. This is how the Linux kernel achieves its object oriented feel.
In this description the socket family selected by the user would have been AF_INET. The socket creation function for that family is inet_create() located in the net/ipv4/af_inet.c file. This function creates the sock structure (section 5.2.1), which holds all of the state information for a socket. It also assigns the protocol operations to the prot pointer based on the protocol selected by the user. This is similar to the proto_ops structure and contains pointer to functions needed by the particular protocol, again this is another example of the object oriented style of the kernel. The inet_create() function initialises all the variables within the sock structure.
For TCP, there is no equivalent to the create function. The inet_create() function has done all the necessary work. Taking the example of the user space connect() function, see figure 5.1 for the flow of control through from the user space to the kernel space.
Figure 5.1: Flow of Control from User Space to Kernel Space