nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

PCI and USB devices in the /sys/devices tree, with uevents and USB hot-plug

Browse source 
PCI devices live at /sys/devices/pci0000:00/<addr> and USB devices under the
xHCI controller that carries their bus, below that bus's root hub usbN;
/sys/bus/pci/devices and /sys/bus/usb/devices are symlinks into it, and every
device has its subsystem and driver links, which is how udev learns SUBSYSTEM
and DRIVER. Writing to a device's uevent now announces it with MODALIAS,
PCI_ID, PRODUCT and the rest, so udevadm trigger covers them, and the USB core
sends add when a device is attached and remove as it goes. The root hub is
announced when the controller comes up, before anything is plugged in.

Checked under QEMU: lspci and udevadm info through the links, udevadm monitor
showing the kernel and udev add event for device_add usb-kbd/usb-mouse and
the remove event for device_del, and a triggered add for usb1 and 1-5.

Known limits: the bus-to-controller mapping is a convention (bus N is the Nth
xHCI in PCI order); PCI bridges are not parents; USB interfaces and
/dev/bus/usb nodes are absent; busybox's lsusb reads /dev/bus/usb and prints
nothing.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
This commit is contained in:
Nexoniarz 2026-10-26 15:51:28 +01:00
commit 8d836c66b2
8 changed files with 526 additions and 67 deletions
Download patch file Download diff file Expand all files Collapse all files

13
docs/architecture/filesystem.md
View file

@ -252,8 +252,8 @@ mounted by init with `mount("sysfs", "/sys", "sysfs", 0, 0)`.
| path | contents |
|------|----------|
| `/sys/bus/pci/devices/0000:BB:DD.F/` | `vendor device class revision subsystem_vendor subsystem_device irq resource config uevent` |
| `/sys/bus/usb/devices/B-P[.P...]/` | `idVendor idProduct bcdDevice busnum devnum speed bDeviceClass bDeviceSubClass bDeviceProtocol bNumConfigurations uevent` |
| `/sys/devices/pci0000:00/0000:BB:DD.F/` (and `/sys/bus/pci/devices/` links to it) | `vendor device class revision subsystem_vendor subsystem_device irq resource config uevent subsystem driver` |
| `/sys/devices/pci0000:00/<xHCI>/usbB/B-P[.P...]/` (and `/sys/bus/usb/devices/` links) | `idVendor idProduct bcdDevice busnum devnum speed bDeviceClass bDeviceSubClass bDeviceProtocol bNumConfigurations uevent subsystem driver` |
| `/sys/firmware/acpi/tables/` | each ACPI table, raw; a repeated signature is numbered from 1 (`SSDT1`, `SSDT2`) |
| `/sys/firmware/dmi/tables/` | `smbios_entry_point` and `DMI`, raw |
| `/sys/firmware/memmap/N/` | `start end type`, the firmware's map as the loader handed it over |
@ -281,9 +281,12 @@ link, `/sys/class/<class>/<name>` and `/sys/dev/{char,block}/MAJ:MIN` as symlink
into it, and input capabilities; `uevent` is writable, and a write is announced
on the uevent netlink socket ([udev.md](udev.md)).
What is missing, compared with Linux: PCI and USB devices in that tree (the
`bus/*/devices` entries are directories rather than links into it),
`/sys/class` entries for them, `/sys/block`, and most of what is writable. PCI `config` is
PCI and USB devices are in that tree too, under `/sys/devices/pci0000:00`, with
the `bus/*/devices` entries as links into it and `add`/`remove` events for USB
hot-plug ([udev.md](udev.md)).
What is missing, compared with Linux: PCI bridges as parents, USB interfaces,
`/sys/class` entries for most devices, `/sys/block`, and most of what is writable. PCI `config` is
256 bytes, because config space is read through port `0xCF8`, which reaches
no further.

29
docs/architecture/udev.md
View file

@ -22,6 +22,10 @@ internal ones: `/dev/tty1` is `4:1` to a Linux program (`linux_tty_rdev` in
## `/sys`: `kernel/fs/sysfs.c`
```
/sys/devices/pci0000:00/0000:00:1f.2/ vendor device class ... uevent subsystem -> ../../../bus/pci driver
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3 idVendor idProduct ... uevent subsystem -> ../../../../../bus/usb
/sys/bus/pci/devices/0000:00:1f.2 -> ../../../devices/pci0000:00/0000:00:1f.2
/sys/bus/usb/devices/1-3 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-3
/sys/devices/virtual/input/input0/ name capabilities/{ev,key,rel,abs} properties
/sys/devices/virtual/input/input0/event0/ dev uevent subsystem -> ../../../../../class/input
/sys/class/input/event0 -> ../../devices/virtual/input/input0/event0
@ -31,9 +35,22 @@ internal ones: `/dev/tty1` is `4:1` to a Linux program (`linux_tty_rdev` in
Symlinks are real (`T_SYMLINK` inodes whose target is generated). `uevent` is
readable (`DEVPATH=`, `SUBSYSTEM=`, `MAJOR=`, `MINOR=`, `DEVNAME=`) and
writable: `echo add > uevent` — which is what `udevadm trigger` does — makes the
kernel announce the device again. A write to a PCI or USB device's `uevent` is
accepted and says nothing yet, because those devices are not in the
`/sys/devices` tree and an event's `DEVPATH` has to name something that exists.
kernel announce the device again. PCI and USB devices announce the same way:
`MODALIAS`, `PCI_ID`, `PCI_CLASS`, `PCI_SLOT_NAME` for a PCI device, `PRODUCT`,
`TYPE`, `BUSNUM`, `DEVNUM` for a USB one.
**PCI devices** are flat under `pci0000:00` however the bridges are wired: the
kernel keeps no bridge tree, so a device behind a bridge is not nested inside
it. **USB devices** sit under the xHCI controller that carries their bus, below
that bus's root hub `usbN`; a hub's children are its siblings, not its
children. The bus-to-controller mapping is a convention (bus N is the Nth xHCI
in PCI order), since the USB core numbers a bus without recording which
controller it came from.
**Hot-plug is real**: the USB core announces `add` when a device is attached
and `remove` as it detaches, and `usbN` is announced when its controller comes
up. With `udevadm monitor`, plugging in a mouse prints the kernel event and
then the same event after udev's rules have run. PCI has no hot-plug here.
The input capability files are what `input_id` reads to decide
`ID_INPUT_KEYBOARD` or `ID_INPUT_MOUSE`. SchOS has two input devices whatever
@ -65,9 +82,9 @@ and regular files in `/dev` are refused.
## What is not there
- PCI and USB devices in `/sys/devices`, and `add`/`remove` events from the
hotplug thread. A USB keyboard works because every keyboard is `event0`, not
because udev knew it arrived.
- USB interfaces (`1-3:1.0`), `/dev/bus/usb` nodes, and PCI bridges as parents.
A USB keyboard works because every keyboard is `event0`; udev now knows the
device arrived but not which interface became the keyboard.
- `hwdb` (`/etc/udev/hwdb.bin`): `udevadm hwdb --update` has not been run in the
image, so `60-input-id` logs "returned non-zero" for the hwdb import. The
properties that matter come from `input_id`.