Initial commit: Schunix as it stands before the SchOS rename

An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.

No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.

kernel/drivers/gpu/vga/vga_pci.c

@@ -0,0 +1,95 @@
+// Display controller -- the first driver to find its hardware by asking.
+//
+// It does not draw anything: kernel/dev/vga.c already owns the framebuffer,
+// and it learned where that is from the bootloader's VBE call. What this adds
+// is a second, independent answer to the same question, from the bus rather
+// than from the BIOS -- and a complaint when the two disagree.
+//
+// That is worth more than it sounds. Three places in the kernel used to
+// hardcode 0xfd000000 as the framebuffer address, and the only reason nobody
+// noticed was that QEMU's stdvga happens to put it there. A disagreement
+// between VBE and the card's own BAR is exactly the symptom that would have
+// shown up first on hardware where the guess was wrong, and until now there
+// was nothing in the kernel capable of noticing it.
+
+#include "types.h"
+#include "defs.h"
+#include "param.h"
+#include "x86.h"
+#include "spinlock.h"
+#include "sleeplock.h"
+#include "fs.h"
+#include "file.h"
+#include "pci.h"
+#include "display.h"
+
+// The framebuffer lives in the first memory BAR big enough to hold a screen.
+// Display controllers commonly expose two apertures -- the framebuffer and a
+// much smaller register block -- and which index they land on varies, so the
+// choice is made by size rather than by position.
+static struct pci_bar *
+framebuffer_bar(struct pci_dev *d)
+{
+  uint64 need = vga_fb_size();
+
+  for (int i = 0; i < 6; i++) {
+    struct pci_bar *b = &d->bar[i];
+    if (b->base == 0 || b->is_io)
+      continue;
+    if (b->size >= need)
+      return b;
+  }
+  return 0;
+}
+
+static int
+vga_pci_probe(struct pci_dev *d)
+{
+  struct pci_bar *bar = framebuffer_bar(d);
+  uint64 vbe = vga_fb_phys();
+
+  // Memory decoding has to be on for the aperture to respond at all. The BIOS
+  // will have done this already to put up a boot splash, but a device we only
+  // reached through enumeration cannot be assumed to have been touched.
+  pci_enable(d, PCI_CMD_MEMORY);
+
+  if (bar == 0) {
+    cprintf("vga: display controller at %x:%x.%x has no framebuffer aperture\n",
+            d->bus, d->slot, d->func);
+    return 0;                           // still ours; nothing more to do
+  }
+
+  if (vbe != 0 && bar->base != vbe) {
+    // Trust VBE: it describes the mode that is actually programmed and being
+    // displayed, which is the thing vga.c is writing into. The BAR is the
+    // card's whole aperture and the mode may sit at an offset within it. Say
+    // so rather than silently preferring one.
+    cprintf("vga: framebuffer disagreement -- VBE says %x, BAR says %x\n",
+            (uint32)vbe, (uint32)bar->base);
+  }
+
+  cprintf("vga: display controller %x:%x, aperture %x (%d MB)\n",
+          d->vendor, d->device, (uint32)bar->base,
+          (uint32)(bar->size / (1024 * 1024)));
+  return 0;
+}
+
+// Matched by class, not by model: every VGA-compatible controller answers
+// class 0x03, and this driver cares about none of the differences between
+// them.
+static const struct pci_match vga_pci_match[] = {
+    { PCI_ANY, PCI_ANY, PCI_CLASS_DISPLAY, 0xFF },
+    { 0, 0, 0, 0 },
+};
+
+// The display vtable lives in kernel/dev/vga.c, which owns the framebuffer;
+// this file only finds the card on the bus. Publishing it here is what makes
+// device_find_class(DEVCLASS_DISPLAY) return something a compositor can use.
+extern const struct display_ops vga_display_ops;
+
+const struct pci_driver vga_pci_driver = {
+    .name  = "vga",
+    .match = vga_pci_match,
+    .ops   = &vga_display_ops,
+    .probe = vga_pci_probe,
+};