On to networking! This is a fairly chunky area in itself, so I
thought I'd start with some peripheral areas: The non-IP networking
stack, and the infrastructure parts of the inet stack. As usual, I
started with the Makefiles and READMEs to get an overview. Not much of
interest.
From there, I looked at the source in the "net" directory
itself. ddi.c and Space.c are a simple module mechanism that has
hopeful comments that it'll be picked up for everything else in the
system. socket.c handles the socket-related system calls. It's mostly
standardised wrappers around the fake-virtual-calls-in-C for the
specific socket types, called from a big switch statement, plus some
helper functions. This is pretty useful to help me get my
bearings. Now's a convenient time to read a few related headers.
Then, net/unix. net/unix/sock.c is annoyingly fiddly, and makes me
think that when people say "In Unix, everything's a file.", it's in an
Animal Farm world where some things are more like files than
others. Maybe Plan 9 gets this right. I should probably take a look
sometime.
Having read net/unix, it's time to start on net/inet. I'll skip the
headers and just concentrate on the C source fils I read:
- proc.c is the usual "convert stats to some text" proc fs
entries.
- loopback.c clearly lives higher up the stack than I
intended to poke around at this point, but is also a good introduction
to how a device should behave - which I guess is a bit out-of-order,
since I've already read the ethernet device driver code.
- eth.c isn't an ethernet device adapter layer. It's
actually a few utlities used by the ethernet drivers to create the
low-level ethernet devices.
- timer.c is messy. I was hoping it would be generic
networking timer-handling code. As it is, it's actually the
implementation of various timer-triggered chunks of code, stored far
away from the code that starts the wait, or is waiting on the timer
handler to do its job. I am not a fan of this structure, since it
doesn't group the code together in a maintainble way.
- protocol.c appears to be the code that sits between IP and
TCP/UDP/ICMP , performing the multiplexing. I originally intended to
read the stack bottom-to-top, so this is slightly out-or-order, but it
gives me a better idea how things are tied together in the
middle. Divide and conquer!
- route.c manages a simple routing table. Way before iptables
and ipchains, there was a simple list of what should be sent to what
interface.
- Finally, skbuff.c handles the skbuffs, or socket
buffers. skbuffs normally live in a linked list, so this is just a set
of utilities to create and destroy the skbuffs, lock and unlock them,
and handle their management within the list, in all cases caring about
thread-safety. Pretty straightfoward and quite pleasant. I was
slightly surprised that it doesn't do anything to do with manipulating
the data in the buffers, arranging buffer headers, etc., so it keeps
nice and simple.
And that's laid the groundwork. Now, I plan to work from the bottom
up, starting with dev.c, and eventually making my way to sock.c. Let's
see how long that takes...
Posted 2018-09-23.