| Filename | Latest commit message | Latest commit date |
|---|---|---|
fastfetch reported "getifaddrs(&ifAddrStruct) failed", and the right answer to
that is not a patch to fastfetch. Asking what interfaces a machine has is
something every networked program does, and on Linux there is exactly one way:
a NETLINK_ROUTE socket. musl implements getifaddrs() over it, so a libc call
that looks like a syscall is really a small protocol conversation -- and without
this side of it every caller fails the same way.
kernel/net/netlink.c is a responder rather than a general socket family. No
event stream, no multicast groups, nothing subscribes to link state: a request
arrives, the whole answer is generated into the socket's buffer, and reads drain
it. That shape is chosen, not a shortcut -- getifaddrs sends a dump and reads
until NLMSG_DONE with MSG_DONTWAIT, so generating at send time means a read
never blocks and the non-blocking flag is honoured for free.
RTM_GETLINK returns one RTM_NEWLINK per interface with IFLA_IFNAME and
IFLA_ADDRESS; RTM_GETADDR returns one RTM_NEWADDR per address with IFA_ADDRESS,
IFA_LOCAL and IFA_LABEL. Anything else gets a bare NLMSG_DONE, because the
caller's next move is a read either way and an unexpected error message is worse
than nothing to read.
The data is not netlink's. Interfaces come from the netdev class and addresses
from lwIP's netifs, exactly as /proc/netif reads them; nothing in the file knows
what an e1000 is. Interface indices matter more than they look -- getifaddrs
matches address records to link records by index, so the two dumps have to
agree. Loopback is 1, netdevs follow from 2.
Verified by reading it back through musl rather than by inspecting the bytes:
lo flags=0x49 fam=-1
eth0 flags=0x1043 fam=17 (AF_PACKET, the MAC)
lo flags=0x49 fam=2 addr=127.0.0.1 mask=255.0.0.0
eth0 flags=0x1043 fam=2 addr=10.0.2.15 mask=255.255.255.0
Correct flags, addresses and netmasks, and the link records pair with the
address records.
One thing this does not close: fastfetch's Local IP module defaults to
default-route-only, which calls ffNetifGetDefaultRouteIfName() and reads
/proc/net/route. SchOS has no routing table and no such file, so the module
still shows nothing -- now for a reason that is about routing rather than about
enumeration. That is the next file to provide.
socktest still passes; the AF_UNIX and AF_INET paths are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
|
||
| .. | ||
| boot.md | ||
| devices.md | ||
| filesystem.md | ||
| graphics.md | ||
| init.md | ||
| kernel.md | ||
| networking.md | ||
| README.md | ||
| schfs.md | ||
| syscalls.md | ||
| usb.md | ||
The system, layer by layer
What SchOS is today. Everything in this directory is built and running; what is merely intended lives in ../plan/.
The names, and what each one covers
uname -s reports SchIFT, the way every Unix reports its kernel rather than
its distribution.
| Layer | Name | What it is |
|---|---|---|
| System | SchOS | The distribution — kernel, userland, tooling |
| Kernel | SchIFT | Multi-core x86-64 kernel with a modular VFS |
| Filesystem | SchFS | Transactional, copy-on-write, the root filesystem |
| API | SchAPI | The native programming interface — designed, not built |
| Compositor | Schcom | Owns the display; v0 runs |
The stack, bottom to top
┌─────────────────────────────────────────────────┐
│ toybox mksh musl first-party cmd/ │ userland
├─────────────────────────────────────────────────┤
│ schinit — PID 1, job manifests, supervision │
├─────────────────────────────────────────────────┤
│ syscall table — Linux numbering, one .inc file │ ← the ABI seam
╞═════════════════════════════════════════════════╡
│ VFS │ sockets │ signals │ mmap │ poll │ procfs │
├──────┴─────────┴─────────┴──────┴──────┴────────┤
│ SchFS │ lwIP │ text/gfx │ buffer cache │
├─────────┴────────┴────────────┴─────────────────┤
│ device model — class vtables, bus binding │
├─────────────────────────────────────────────────┤
│ drivers: xHCI e1000 virtio-gpu VBE IDE PS/2│
├─────────────────────────────────────────────────┤
│ scheduler │ paging │ traps │ IRQ │ SMP │ DMA │ SchIFT core
└─────────────────────────────────────────────────┘
▲
UEFI loader (boot/uefi)
The two seams that matter are the syscall table and the device model. Above the first, software is ordinary and portable — musl and toybox are unmodified. Below the second, a driver never names its consumer and a consumer never names a driver.
Where it came from
SchOS began as xv6 and is now mostly something else. What survives from xv6 is the shape of the process table, the sleep/wakeup discipline, and the buffer cache. What has been replaced: the scheduler and trap path (rewritten for x86-64 and for more than one processor), the memory manager, the entire filesystem, the syscall layer, and every driver.
That inheritance is worth knowing when reading the code, because the parts that still look like xv6 follow xv6's conventions and the parts that do not, do not.
The documents
Read in this order if you are new:
| boot.md | Firmware to the first userspace process. The shortest path through the whole system. |
| kernel.md | Memory, processes, scheduling, traps, signals, SMP. |
| syscalls.md | The one table everything is generated from, and how a musl binary runs unmodified. |
| filesystem.md | The VFS, the buffer cache, mounts, procfs. |
| schfs.md | The copy-on-write root filesystem. |
| devices.md | Buses, classes, binding, and the vtables consumers talk to. |
| usb.md | xHCI, the USB core, and the three class drivers. |
| graphics.md | Framebuffer, text rendering, the console, and PSOGM. |
| networking.md | NIC drivers, lwIP, and both socket families. |
| init.md | schinit and the job manifests. |
Three rules that hold across all of it
The kernel and the host tools compile the same SchFS source. mkschfs
cannot disagree with the kernel about the on-disk format, because there is only
one implementation. Format bugs are found on the host, where a test takes a
second instead of a boot.
Syscalls are declared in exactly one place. kernel/sys/table.inc.
The constants, the dispatch table and the Linux translation map are all
generated from it, so a syscall cannot be half-registered.
A list you can read beats a list assembled by side effects. Drivers are
written out by hand in kernel/drivers/registry.c rather than collected by a
linker section, and platform devices are registered in one function rather than
inside each driver's init. The tradeoff is deliberate: self-registration is
nicer to write, and it means the list of what is in your kernel is not written
down anywhere you can read.