XPost: comp.lang.c   
   From: cross@spitfire.i.gajendra.net   
      
   [Note: Following up to alt.os.development]   
      
   I think there's an interesting discussion to be had here, but I   
   think it would be best outside of comp.lang.c.  I wish there was   
   a comp.* group for this (bring back comp.os.research!) but   
   alt.os.development is probably closest.   
      
   In article ,   
   Scott Lurndal  wrote:   
   >Salvador Mirzo  writes:   
   >>[snip]   
   >>Would you elaborate or point out an article or book that could clarify   
   >>the ideas that have made you to make such remark?  Sounds interesting.   
   >   
   >When the BIOS (as was originally intended) controls all the I/O interfaces,   
   >it fundamentally limits access to new and experimental devices, and limits   
   >the ability to generationally improve the hardware (e.g. Compare NVMe driver   
   >interface with a legacy ISA device vis-a-vis the OS interface to the device).   
      
   It certainly means that, for example, an OS-provided filesystem   
   that can only access a storage device via the BIOS can't use   
   those devices.  These primitive early PC "operating systems"   
   didn't provide any real memory safety, or try to prevent   
   programs from accessing the hardware directly, bypassing the OS.   
   So in theory a user program could talk directly to the device,   
   but then it has to go implement a filesystem (or something   
   equivalent) itself, and every program that wants to use that   
   data has to know how to talk to that device.  That obviously   
   defeats the purpose of having the OS provide the abstraction.   
      
   >It requires the mainboard manufacturer that provides the BIOS include   
   >support for all new third-party hardware innovations.  Given the BIOS   
   >was orignally a ROM, such systems were extremely difficult to update   
   >and there was no way to accomodate new third-party hardware without   
   >bypassing the BIOS entirely.   
      
   +1e6   
      
   >The expansion ROM on PCI was an attempt to remedy this, but clearly   
   >falls short when supporting multiple hardware families (e.g. various   
   >RISC and CISC architectures) pushing the burden to support new   
   >or different operating systems upon the device hardware manufacturer;   
   >which either requires differnent SKUs for each generation of each   
   >supported processor family, a significant burden on the device hardware   
   >manufacturer.   
      
   I'm going to quibble with this one a little bit.   
      
   To my mind, modern firmware, including BIOS-like systems,   
   provides three fundamental facilities:   
      
   1. It provides an abstraction interface for systems software,   
      both the traditional BIOS role, but also a way to decouple   
      emulate legacy hardware interfaces so that hardware   
      advances are decoupled from systems software.  Consider   
      running DOS on a machine with a USB keyboard and mouse;   
      "BIOS" gives me a way to emulate an AT or PS/2 keyboard.   
      (Don't get me started on the dumpster fire that is SMM.)   
   2. It's a place to do all sorts of platform enablement.  For   
      example, on modern x86 systems, firmware does DRAM timing   
      training, IO bus enumeration and initial allocation and   
      assignment of physical address space for MMIO, bridge   
      assignment and configuration, etc.   
   3. It solves a necessary bootstrapping problem.  Often, an   
      operating system is installed on some storage device that   
      sits on some controller somewhere.  But in order to load the   
      OS, I have to be able to initialize and drive the controller   
      "enough" to be able to load the OS (or at least some kind of   
      boot loader that knows to to load the OS).  Firmware that   
      understands enough of the platform to do the bare minimum to   
      drive hardware and load a more elaborate bootstrap let's me   
      boot a real system.   
      
   Options ROMs were meant as part of the solution to last problem:   
   give the hardware enough smarts so that very simple code running   
   in a very constrained early boot environment could get something   
   from the device itself that lets the firmware drive the device   
   well enough to load more capable software from it.  With a   
   well-defined and sufficiently capable interface between the   
   option ROM and firmware, third-party hardware designed well   
   after a system was put in place can be used on that system,   
   provided the OS it uses has been updated so that it can drive   
   the new hardware.   
      
   I don't think this is a bad way to do things, to be honest;   
   interfaces are fundamental for isolation in software.  And the   
   way that OpenFirmware did it was actually pretty nice: provide   
   an interpreter for a sufficiently general language (FORTH) in   
   firmware, and store little programs in that language in ROM on   
   the device that let firmware drive the device enough to load a   
   real OS.  Pair firmware with a little bit of non-volatile   
   storage like battery-backed CMOS so that you can store a few   
   variables, and you're good to go.   
      
   But of course, the expression of the idea in UEFI has become a   
   bloated and insecure mess that creeped into everything, and you   
   can't really get rid of it, even once the OS is running.   
      
   >BIOS is a least-common-denominator hardware abstraction interface.   
      
   This times 100.  BIOS wasn't just there to bootstrap, it was   
   meant to be _the_ interface to the hardware, as you point out.   
   That was fine on the anemic Z80-based machines that CP/M ran on,   
   but it's awful once you want to do something more complex.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)