SystemIO conflicts are not firmware bugs

2 comments

• eqvinox 14 hours ago
  > the internet will tell you that PC firmware developers are incompetent³

  > ³ I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion

  If anything, isn't this evidence the vendor should've paid someone to write an ACPI driver for Linux? :-)

  [-]
  • lmz 13 hours ago
    No. Unless the hardware had Linux stickers on it.
  • mitxela 10 hours ago
    Why should they? Would they sell more hardware if they did? And why Linux? Shouldn't they write an ACPI driver for Haiku first? Companies do what makes money, period. Activist companies have been almost completely wiped out by this stage of capitalism.
• dataflow 11 hours ago
  Two questions:

  1. How does the kernel detect the conflict?

  > you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime

  2. How does the kernel prevent the firmware from running anything?

  [-]
  • mitxela 10 hours ago
    ACPI firmware is not code that runs by itself. It is code that the kernel interprets. If the kernel doesn't interpret it, it won't run. SMM firmware runs by itself but also can't interact with ACPI locks anyway.
  • p_l 9 hours ago
    For (1) - ACPI is how the kernel knows what addresses maps where. And when a driver claims the same address space, it knows there's a conflict