Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.lang.c,alt.os.development
Subject: Re: [OSDev] How to switch to long mode in x86 CPUs?
Followup-To: alt.os.development
Date: Sun, 2 Mar 2025 20:26:31 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vq2etn$rc6$1@reader1.panix.com>
References: <871pvje5yq.fsf@onesoftnet.eu.org> <JdFwP.46247$SZca.36276@fx13.iad> <87v7ssi2ec.fsf@example.com> <cU%wP.111376$_N6e.73667@fx17.iad>
Injection-Date: Sun, 2 Mar 2025 20:26:31 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="28038"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 6274
Lines: 106

[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.