[TUHS] Question about BSD disklabel history

[Theodore Ts'o]

On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote:
> On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> Ironically, the UEFI people have done something _similar_ to OF in the
> form of AML (ACPI Machine Language), which is a byte-code
> serialization ASL (ACPI Source Language); presumably that's system
> independent. The idea of a p-code representation is about where the
> similarity ends, though: AML exposes a mechanism to talk to the UEFI
> OS for a whole slew of stuff, which is rather unlike what OF did

ACPI (Advanced Configuration and Power Interface) predates UEFI.  ACPI
was released in 1996, and was originally intended to be a replacement
for APM (Advanced Power Management).  With APM, the OS would crowbar
itself into x86 Real mode in order to call into the APM BIOS in order
to suspend the laptop, fetch power management events from the APM,
etc.  Later on, APM grew 32-bit protected mode interfaces, but
effectively, the OS would completely lose control of the thread of
execution while running APM BIOS code, which made life "exciting" for
OS engineers.

So ACPI was originally intended to solve a problem, where the OS could
incorporate a byte code interpreter to do those things that would be
very hardware specific (for example, how to diddle the various random
I/O ports on a HP laptop to bring the perpipherals into a low power
state, which of course would be completely different on a Dell or IBM
laptop.  Previously, the APM bios was the abstraction layer; ACPI was
the new abstraction layer.

UEFI came later.  UEFI was the second system disease replacement for
EFI (extensible firmware interface), which Intel had developed.  EFI
was an implementation that attempted to retain full backwards
compatibility with the de factor standard originally established by
the IBM BIOS.  UEFI was an attempt to completely rework the interface
between the OS boot code (which before would talk to the BIOS
interface) with the all new singing, all dancing UEFI interface.
Being a second system, of course it was made horribly complicated, so
as to meet all of the requirements that might be dreamed up by the
industry committee that put it together.

Normally, once the OS has gotten to a certain point in its OS
initialization, the OS can "terminate UEFI services".  At that point,
the OS can no longer call into the UEFI functions --- but it also
doesn't have to worry about the UEFI code servicing an interrupt take
taking control of the CPU away from the OS.

However, the OS can still execute various ACPI functions, assuming the
OS has its own AML interpreter.  (Of course, the UEFI BIOS has its own
AML interpreter --- and scheduler --- and everything else that a
simple OS might have.)  Ron Minnich has a number of really good
presentations about the "joys" of working with UEFI.  See the YouTube
video, "Replace your Expoit-ridden Firmware with Linux"[1] and prepare to
be horrified about what horrors lurks in the heart of UEFI....

[1] https://www.youtube.com/watch?v=iffTJ1vPCSo

So you can very much be *not* using UEFI, and still be using ACPI ---
either if you are using a pre-2004 computer, or if you are using a
more modern platform which uses LinuxBoot.

						- Ted