I spent a little while reworking the network stack in the m68k OS code. The idea is to end up with a reasonably generic stack: ideally, like Linux and friends, the OS code shouldn't really care about what kind of network adaptors are plugged in, and should support a variety of higher-level network protocols.
Having done a fairly substantial refactor, I was able to get basic protocol handling and routing working. The network stack knows how to enumerate attached network adaptors and to instantiate one kernel process per adaptor to deal with incoming network traffic. Each network protocol is written as a separate module, conforming to a common API; these are "discovered" at boot time, after the system hardware discovery phase, and started independently.
I made a 10/100Mbps Ethernet adaptor using an ENC624J600; I've written about this network card in an earlier log. On boot, the OS detects the network card and loads its driver; the network stack creates a virtual device, eth0, to represent the Ethernet interface. Multiple network adaptors are supported - a separate virtual device is created for each card.
The screenshot below shows the OS booting, performing hardware discovery and other startup tasks, starting the various network protocol drivers, and finally dropping into the interactive shell (lines beginning with the "$" prompt). The output looks quite Linux-ey, but it's not Linux - all of the software running on the system is my own work.
Having reached the shell, I then enter some "route" commands to set up the kernel IPv4 routing table (I have implemented basic IPv4 routing), and use the "netif" command to add an IPv4 address (172.16.0.12) to interface eth0. Finally, the "schedule" command starts the task scheduler. The system is now ready to deal with network traffic!
So, starting from the bottom of the network stack: after writing an Ethernet protocol driver, I added support for ARP. This enables the kernel to maintain a mapping between hardware addresses (e.g. MAC addresses) and protocol addresses (e.g. IPv4 addresses). All ARP traffic is handled transparently within the kernel; once the system has been up for a while, and has gathered a bit of ARP traffic, it's possible to dump the contents of the ARP table and see details of various network neighbours. All address-handling is fully generic; the output below just happens to show Ethernet and IPv4 addresses.
Next up, after ARP, I wrote a very basic ICMP driver. This enabled me to reach an important and deeply satisfying point: pinging the board! The screen-grab below shows the result of pinging the MC68000 system from a Linux host elsewhere on the LAN. The latency isn't great; this is mainly a consequence of the rather primitive task-scheduling logic. I hope to improve this in future.
I need to do a little more work on the low-level protocols before I can make a serious attempt at implementing TCP and friends. A half-decent TCP implementation is going to take a lot of work, but it should be an interesting challenge.
It's been a long time since I wrote an update on the project. My excuse is that I have been working on a new hardware platform based on a Motorola 68030 processor. This system will run the same OS code as the MC68000 system; I'm going to add virtual memory support to the code. The main focus at the moment is on designing a workable memory subsystem using 72-pin SIMMs. This has been a lot of fun, and I'll probably set up a separate project page soon to describe my work.