From C++ to the Linux Kernel: Connecting the Layers

I’ve been learning C++, but somewhere between pointers, streams and sockets, I realised the more interesting lesson was understanding how the layers underneath Linux connect.

Consider a seemingly simple line:

int fd = socket(AF_INET, SOCK_STREAM, 0);

It looks simple:

AF_INET      -> IPv4
SOCK_STREAM  -> byte-stream socket
socket()     -> create a socket
fd           -> returned file descriptor

But what does fd actually represent?

Following the Socket

I created a socket and kept the process alive:

python3 -c 'import socket,time,os; s=socket.socket(); print("PID:",os.getpid(),flush=True); time.sleep(300)' &
PID=$!

Then inspected its file descriptors:

ls -l /proc/$PID/fd

And there it was:

0 -> /dev/pts/1
1 -> /dev/pts/1
2 -> /dev/pts/1
3 -> socket:[15292]

FD 3 is not the socket itself. It is the process’s handle to a kernel-managed socket object.

The picture starts looking like this:

Application
    |
    | socket()
    v
System-call interface
    |
    v
--------------------
   Kernel boundary
--------------------
    |
    v
Process FD table
    |
    | FD 3
    v
Kernel socket object
    |
    v
TCP/IP stack

Watching the Boundary

Then I ran the same experiment through strace:

strace -e trace=socket,close,write,clock_nanosleep \
python3 -c 'import socket,time,os; s=socket.socket(); print("PID:",os.getpid()); time.sleep(5)'

The interesting part:

close(3) // python calling multiple liabires 
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 3 
write(1, "PID: 1729\n", 10) = 10 // the print stantment
clock_nanosleep(...)  // the sleep statement
close(3) = 0 // program closes

Now the layers connect.

C++:
int fd = socket(...);

        |
        v

strace:
socket(...) = 3

        |
        v

/proc/<PID>/fd:
3 -> socket:[15292]

strace shows the interaction with the kernel.

/proc/<PID>/fd shows the resulting process state.

Even something as ordinary as print() eventually becomes:

print(...)
   |
   v
stdout
   |
   v
write(1, ...)
      ^
      |
    FD 1

And suddenly pipes and redirection make more sense too.

program > output.txt
program1 | program2

Underneath, the shell is manipulating file descriptors and connecting processes together.

The Bigger Lesson

None of these concepts are particularly obscure individually:

C++
POSIX
syscalls
file descriptors
/proc
sockets
pipes
strace
networking

The interesting part is understanding how they connect.

Code
 -> library/runtime
 -> syscall
 -> kernel
 -> process state
 -> kernel object
 -> network/filesystem/device

That is what I’m finding valuable about learning C++.

Not simply learning another programming language, but developing the ability to follow an operation through the system.

Linux starts becoming less of a collection of commands to memorize and more of a system whose behaviour you can trace, observe and reason about.