[TUHS] Re: Porting the SysIII kernel: boot, config & device drivers

On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal <pnr(a)planet.nl> wrote: Let's not forget that the diversity of systems is 1000s of times greater than it was in the early days of Unix. There were just two busses (Unibus and QBUS) in pdp-11 unix. There were a limited number of peripherals that could live at a limited number of CSRs and compatibility requirements of other DEC OSes meant that most of the 3rd party cards were compatible with DEC gear, though there were exceptions. There was no hot plug, there was no need to hierarchically assign address pools for things like PCIe hot-plug. There was no USB. There were only a very limited number of keyboard and graphics configurations. VAXen increased the number, but not by a huge amount, at least in the early days before new busses were introduced). As such, the unixes from the system III era simply didn't have any notion of this diversity. So trying to layer it in will be quite difficult. The SoC space has become huge, with memory being mapped in different locations, busses being different, etc. There's been much nasty said about FDT and ACPI, but they do solve real problems: how to enumerate this diversity to the OS in a way that's sane and might not always be as simple as returning a specific number but that requires hardware access to answer even basic questions (because, say, the CPUs were wired this way or that and you have to read those wirings). Linux, even in Linuxboot environments, still uses ACPI, FDT and UEFI to get the job done, and the code there isn't horrific. V7 unix for the PDP-11 shipped with maybe 25 drivers total for the whole system, and many of them were quite niche... virtio solves a different problem, though: It's goal is to provide THE interface for mass storage, THE interface for networking, etc so that hypervisor clients can limit their drivers substantially and not have to deal with the thousands of drivers normally needed. ACPI/FDT just try to make the non-self-describing aspects of the hardware described. Which is a different target market (so that one can hook up the right driver of the thousands to choose from when the OS autoconfig's the devices by whatever means it does that, even Linux and System V have this concept, though with radically different code than the BSDs). I'd worry that 'use the BIOS' bit here leads to the ugly UEFI/ACPI hybrid to be generic enough to describe everything. Now, I don't disagree with the org chart args for why they are so large outside of linuxboot, but they do fill a vacuum that would otherwise exist. Warner