net: a network *class*, so the stack stops knowing what an e1000 is

The TCP/IP stack reached straight into the first driver anyone wrote.
net.c called e1000_present(), the lwIP glue was named netif_e1000.c and
called e1000_transmit(), and include/defs.h declared the driver's
internals to the whole kernel. The second NIC driver would therefore
have arrived with a near-identical copy of the glue file and a patch to
the protocol stack, which is the arrangement include/device.h was
written to prevent -- the e1000 even said so, with `.ops = 0, // no
class vtable yet; there is no net class`.

There is now. A driver publishes a struct netdev_ops -- transmit,
receive, mac, link_up -- and is finished: it never mentions lwIP, and
nothing above it learns its name. The display class was already this
shape; this is the same shape for networking, and the two now read the
same way in kernel/dev/device.c.

What that made possible immediately:

  - One netif per bound device instead of one per driver. lwIP's glue is
    netif_eth.c, it takes a struct device, and it holds up to NETIF_MAX
    interfaces. net.c attaches every network device it finds and starts
    DHCP on each, because which interface the network answers on is not
    ours to decide.
  - /proc/netif lists all of them, one block of fields each, with the
    interface name and the driver that claimed it.
  - The ARP self-test moved from the e1000 to the class. Nothing in it
    was chip-specific, and it is the first thing anyone will want to run
    against the next driver. Still `echo n > /proc/sysrq`.
  - Private headers live with their driver: e1000.h was in include/,
    where exactly one file could use it. The driver build now adds the
    driver's own directory to the include path.

The e1000 also drives more than one card. Its probe() refused the second
outright, because there was a single static instance -- so a machine
with two of them drove one and silently ignored the other. Instances are
an array now, and the instance is hung on dev->priv by a new optional
`attached` hook that the bus calls once the device exists. probe() runs
before device_add(), so there was previously nowhere to put it; that is
the whole reason the hook exists rather than a line inside probe.

QEMU gets an explicit NIC on every target (QEMU_NET). The default device
happens to be an e1000 on this machine type today, which is exactly the
sort of thing that stays true until a QEMU release changes it and the
network stops being exercised without anyone noticing.

Verified:
  - bootcheck -Net passes, 48 [ok], no failures -- including the moved
    self-test and two new checks that /proc/netif names both the
    interface and the driver behind it, which together say the stack
    went through the class rather than through a driver it was compiled
    to know.
  - Two NICs attached by hand (-device e1000 twice, second with its own
    MAC): eth0 and eth1 both attach, each reports its own MAC in
    /proc/netif, and each gets its own DHCP lease. Before this commit
    the same machine produced one interface.
  - make schfs-check still passes in full.

One trap worth recording: moving a header broke the build for anyone
with stale .d files -- make stopped with "No rule to make target
'include/e1000.h'". CFLAGS gains -MP, which emits a phony target per
header so a moved or deleted one can never wedge the build again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-08-15 16:42:34 +02:00
commit 20cc673a41
16 changed files with 729 additions and 367 deletions

View file

@ -79,7 +79,7 @@ KERN_NET += $(addprefix $(BUILD)/lwip/core/, \
KERN_NET += $(addprefix $(BUILD)/lwip/core/ipv4/, \
acd.o dhcp.o etharp.o icmp.o ip4.o ip4_addr.o ip4_frag.o)
KERN_NET += $(addprefix $(BUILD)/lwip/netif/, ethernet.o)
KERN_NET += $(addprefix $(BUILD)/kernel/net/lwip/, sys_arch.o netif_e1000.o)
KERN_NET += $(addprefix $(BUILD)/kernel/net/lwip/, sys_arch.o netif_eth.o)
KERN_PROC = $(addprefix $(BUILD)/kernel/proc/, \
proc.o)
@ -173,6 +173,22 @@ endif
# virtio-gpu wins the display class, stdvga carries the splash and text console.
QEMU_DISPLAY = -vga std -device virtio-gpu-pci
# A network card, on every QEMU target.
#
# Spelled out rather than left to QEMU's default NIC. The default exists and is
# an e1000 on this machine type today, which is exactly the sort of thing that
# is true until a QEMU release changes it -- and then the network silently stops
# being tested rather than failing loudly. Naming the device also means `make
# qemu` and `bootcheck -Net` are running the same hardware.
#
# User-mode networking: the guest gets 10.0.2.15 by DHCP, the host is 10.0.2.2,
# and no privileges are needed. A bridge or a tap would need root and would put
# the guest on the real network, which is not what a development boot wants.
#
# To point the driver at different hardware once there is a second one, override
# it: make qemu QEMU_NET='-netdev user,id=net0 -device rtl8139,netdev=net0'
QEMU_NET = -netdev user,id=net0 -device e1000,netdev=net0
# An absolute pointing device, on an xHCI controller.
#
# A PS/2 mouse is relative, so inside a VM the guest cursor and the host's
@ -325,7 +341,12 @@ XFLAGS += -ftls-model=local-exec
# answer that cannot change during a build.
NO_SSP := $(shell $(CC) -fno-stack-protector -E -x c /dev/null >/dev/null 2>&1 && echo -fno-stack-protector)
CFLAGS = -fno-pic -static -fno-builtin -fno-strict-aliasing -Wall -MD -ggdb -fno-omit-frame-pointer
# -MP with -MD: emit a phony target for every header, so that *moving* or
# deleting one does not wedge the build. Without it the stale .d still names the
# old path and make stops with "No rule to make target 'include/e1000.h'" --
# which happened the day that header moved next to its driver, and the only
# cure was knowing to delete the .d by hand.
CFLAGS = -fno-pic -static -fno-builtin -fno-strict-aliasing -Wall -MD -MP -ggdb -fno-omit-frame-pointer
CFLAGS += -ffreestanding -fno-common -nostdlib -I./include $(XFLAGS) $(OPT)
CFLAGS += $(NO_SSP) $(CFLAGS_EXTRA)
@ -516,7 +537,7 @@ ovmf: $(OVMF_CODE) $(OVMF_VARS)
all: $(OVMF_CODE) $(OVMF_VARS)
qemu-uefi: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -machine pc-i440fx-9.2 -drive if=pflash,format=raw,unit=0,readonly=on,file=$(OVMF_CODE) -drive if=pflash,format=raw,unit=1,file=$(OVMF_VARS) -drive file=fat:rw:$(BUILD)/esp,index=0,media=disk,format=raw -drive file=$(BUILD)/schfs.img,format=raw,index=1,media=disk -m 1G -smp 1 $(QEMU_ACCEL) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT)
$(QEMU) -machine pc-i440fx-9.2 -drive if=pflash,format=raw,unit=0,readonly=on,file=$(OVMF_CODE) -drive if=pflash,format=raw,unit=1,file=$(OVMF_VARS) -drive file=fat:rw:$(BUILD)/esp,index=0,media=disk,format=raw -drive file=$(BUILD)/schfs.img,format=raw,index=1,media=disk -m 1G -smp 1 $(QEMU_ACCEL) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) $(QEMU_NET)
# Build the ramdisk-root variant. This is a target rather than just
# "make RAMROOT=1" because toggling RAMROOT changes CFLAGS (-DRAMDISK_ROOT),
@ -579,7 +600,7 @@ schos.iso: $(BUILD)/kernel/kernel $(BUILD)/uefi/BOOTX64.EFI sysroot-install
# all, so a kernel that still secretly depends on one fails here rather than
# in someone's optical drive.
qemu-iso: schos.iso
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_ACCEL) \
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_ACCEL) $(QEMU_NET) \
-cdrom schos.iso -boot d \
-m 1G -smp 2 -machine pc-i440fx-9.2
@ -680,9 +701,13 @@ $(BUILD)/kernel/dev/%.o: kernel/dev/%.c
# `$(dir $@)` rather than a fixed path: drivers are grouped into one directory
# per device class (gpu/, net/, bus/, usb/), so the output directory varies with
# the target and a hardcoded mkdir only creates the top one.
# -I on the driver's own directory, so a driver can keep its register
# definitions next to its code instead of in include/. include/ is for headers
# the rest of the kernel needs; a chip's register map is not one of those, and
# e1000.h sat there for a year being included by exactly one file.
$(BUILD)/kernel/drivers/%.o: kernel/drivers/%.c
@mkdir -p $(dir $@)
$(CC) $(CFLAGS) -c $< -o $@
$(CC) $(CFLAGS) -I$(dir $<) -c $< -o $@
$(BUILD)/kernel/fs/%.o: kernel/fs/%.c
@mkdir -p $(BUILD)/kernel/fs
@ -977,11 +1002,11 @@ OVMF_DRIVES = -drive if=pflash,format=raw,unit=0,readonly=on,file=$(OVMF_CODE) \
# insisting on it, which is what you want when the point is to find out why the
# host has no /dev/kvm rather than to quietly get a slow machine.
qemu-kvm: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -enable-kvm -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) -cpu host \
$(QEMU) -enable-kvm -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) $(QEMU_NET) -cpu host \
$(OVMF_DRIVES) -m 1G -smp 2 -machine pc-i440fx-9.2
qemu: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) $(QEMU_ACCEL) \
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) $(QEMU_ACCEL) $(QEMU_NET) \
$(OVMF_DRIVES) -m 1G -smp 2 -machine pc-i440fx-9.2
# The root filesystem. Built from the staged sysroot; the kernel mounts it as
@ -1001,7 +1026,7 @@ $(BUILD)/schfs.img: $(MKSCHFS) $(BUILD)/sysroot.stamp
#
# Once up: cat /proc/schfs
qemu-schfs: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_ACCEL) \
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_ACCEL) $(QEMU_NET) \
$(OVMF_DRIVES) -m 1G -smp 2 -machine pc-i440fx-9.2
# -----------------------------------------------------------------------