Re: [OSDev] How to switch to long mode in x86 CPUs?

[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 <cU%wP.111376$_N6e.73667@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

Salvador Mirzo <smirzo@example.com> 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.