据我所知，内核提供了软件和硬件之间的链接，因此内核必须指导操作系统应用程序进行的系统调用，对吗？那么不同的 I/O 地址映射是否意味着内核必须以不同的方式编程？请阅读下文，因为我不认为我对这个问题的表述非常准确。
让我详细说明一下，如果我错了，请纠正我，因为这是我对几篇文章所述内容的理解。我将使用 x86 系列作为我的示例的基础。x86 处理器使用 INT 命令以及称为中断向量表的索引将 INT id 映射到所需例程的正确位置（例程和 IVT 位于 BIOS 中，对吗？）。例程本身的编写方式是，它们可以命令特定于计算机系统的硬件根据所用硬件的协议执行任务。这允许操作系统进行系统调用并与硬件通信，而无需了解特定于系统的硬件或 I/O 映射。操作系统与硬件通信所需的只是所需特定 ISR 的 id。由于内核是硬件和软件之间的链接，我猜测操作系统运行的应用程序甚至不需要知道 ISR id#，它们只是告诉内核它们想要例如将数据 X 写入硬盘，内核将数据 X 中继到正确的 ISR，然后将数据写入硬盘。因此，两个系统完全相同，只是针对不同的任务使用不同的 ISR id#，是否需要略有不同的内核？
这是否也意味着加载内核的引导扇区也将依赖于 ISR id 映射，因为需要进行从 HDD 读取的系统调用才能加载内核？
如果这个位置不对，我深表歉意，但我读到这是解决硬件相关问题的正确位置。谢谢！
答案1
关于您引用的 INTh 命令（请参阅：BIOS 中断调用)，您说得对，这曾经是操作系统访问低级硬件的方式。在现代机器中，这些调用（如果执行）通常最终进入 CSM（兼容性支持模块，至少是 AMI 的说法），它可以处理这些请求。在视频 BIOS 调用的情况下，如果存在视频 BIOS，它将执行视频 BIOS 中的代码。我曾作为 BIOS 开发人员使用过英特尔 IGP，作为最终映像的一部分，我们有一个来自英特尔的工具，我们将其视频 BIOS 作为一个 blob 烘焙进去。
同样，BIOS 可以实现“模拟”版本的调用来读取/设置 RTC。现代操作系统根本不会执行所有这些旧式处理程序，因为它不需要依赖 BIOS 来获得该支持 - 例如，可能有一个内核驱动程序知道如何直接与 PCH 通信以干扰 RTC 设置。
可以想象，这非常非常慢，现代软件已不再使用。相反，操作系统拥有提供抽象层所需的硬件，该抽象层允许图形应用程序利用 GPU 的驱动程序执行这些任务；当然，从软件的角度来看，该设备通常是 PCIe，并且是内存映射的。
同样，如果您查看下面的 Linux 存储堆栈，您将看到底层内核驱动器负责与硬件通信，而无需使用 BIOS——所有执行的代码都来自您的内核。
现在，关于不同的 I/O 地址映射等，回想一下 x86 既有 I/O 地址空间，也有内存地址空间。如果您回想一下即插即用，在启动时，您的 BIOS 将遍历并枚举 PCI 设备树，对于现代系统来说，它基本上涵盖了您的所有外围设备，至少从 SW POV 来看是这样（即 DRAM 控制器位于 PCIe 总线 0 上，您的 USB 控制器是来自 SW POV 的 PCI 设备，等等）。使用 BAR（基址寄存器），BIOS 知道目标设备需要多少内存以及需要什么类型的内存，并且它会尽力满足请求。
最终映射在交接时传递给操作系统，操作系统可以选择遵守这一点，或执行自己的枚举阶段。例如，Linux 具有“怪癖”，您可以在操作系统启动之前将其应用于给定的 PCI 设备 ID，您可能还记得内核启动参数，这些参数会影响分配的内存量、最终的 IRQ 等。