| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Nexoniarz
|
0331d548c4 |
net: an RTL8139 driver, and the e1000 stops refusing the PCIe parts
Two NICs, and unlike the RTL8111 last commit, QEMU emulates both -- so both are tested rather than reasoned about. **RTL8139** is its own driver and not a mode of the 8169, because it is its own chip. No descriptor rings: the receiver is one circular buffer the chip writes packets into back to back behind four-byte headers, and the transmitter is four fixed slots. Putting both programming models behind one set of function pointers is how a mode flag ends up threaded through every path. Three details are the whole driver. CAPR runs sixteen bytes behind the true read position -- a quirk of the part, not an off-by-one. WRAP means the chip runs a packet past the end of the buffer rather than splitting it, so the 8 KB buffer is allocated as 8 KB + 16 + one maximum frame; getting that wrong is a chip writing past its allocation at line rate. And a length field of 0xFFF0 means "still writing this one", so treating it as a length copies a partial packet and loses the alignment for everything after it. **The e1000 now matches the PCIe 8257x parts.** Its header refused them, with a note saying they "differ in NVM access and initialisation, and claiming a device this driver has not been shown to initialise is worse than not claiming it". That was right, and the second half is answerable: QEMU emulates the 82574L, so it can be *shown* to initialise. What differs turned out to be one register. EERD moved its address field from bits 8-15 to bits 2-15 and its done bit from 4 to 1; the rings, RCTL, TCTL and ICR are identical. So there is a per-instance flag for the NVM layout and seven more ids -- not a second copy of four hundred lines of ring code. The wrong pair of constants fails silently, reading the wrong word or waiting for a bit that never sets, and the MAC comes out as zeroes; that is why it is named in the header rather than papered over. Still refused: the ICH/PCH parts (82562, 82577-82579, I217-I219), which put the PHY behind a MAC-PHY interconnect and need a different bring-up nothing here can test. Tested, each booted alone: rtl8139 (10ec:8139) and 82574L (8086:10d3) both bind, read a real MAC, complete DHCP and ping 4 of 4 with no loss. The classic 82540EM does the same, which is the regression that mattered for the NVM change. Both supported display configurations: one boot each, no traps, no panics, socktest and memfdtest green. Also recorded: the Chromebox CN62 carries an RTL8111, not an Intel part, so last commit's driver covers it too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Nexoniarz
|
57aff40228 |
docs: four directories, and a rule for when a thing leaves the roadmap
docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.
A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.
So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.
schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.
Three corrections found on the way, all load-bearing:
* projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
* The root README said "No TCP/IP" months after the stack landed.
* history/kernel.md sec.7 was marked "in progress" on a problem that process
groups solved.
Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
|
||
|
Nexoniarz
|
20cc673a41 |
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>
|
Renamed from include/e1000.h (Browse further)