OSDev.org

I'm developing on x64 and for moving forward (a more flexible timer than the PIT, multiprocessing, etc.) I think I'm going to have to support ACPI. Has anyone had experience reading the ACPI tables in userland?

My OS is a microkernel and it's a lot of work to support ACPI (either rolling your own interpreter or porting ACPICA), so I'm interested in keeping this out of the kernel.

My plan is to have my device manager service (a user space process) parse the ACPI tables, and my kernel will boot using a primitive PIT timer for scheduling threads and a single processor until my device manager reports the addresses of the APIC timer.

In my experience, the only thing you need ACPI for is to map PCI interrupts for devices that don't support MSI or MSI-X. Perhaps also to initialize motherboard states which you must do by fooling the system into believing you are the latest Windows version(s).

I don't think you can run ACPI in user space. It requires interrupts.

You certainly don't need ACPI to discover the address of the APIC timer. It's always at the same address.

This just shows your limited understanding of what ACPI is.
ACPI is a must for the following cases:
- discovering any devices not discoverable otherwise (ISA, PS/2, serial, anything non-pci, ...)
- discovering routing/locations/ownership of devices (PCI, USB, I2C, ...) by inspecting _ADR/_PRT and similar objects
- memory, cpu hotplug/unplug
- shutting the system down, or suspending (_S1 - _S4)
- managing system resources like IO, memory, etc ranges (a kernel will inspect all _CRS buffers and reserve all to prevent conflicts)
- battery stats (percentage, charging/discharging, etc)
- AC adapter status
- keyboard fn+X shortcuts and other OEM-defined keys
- backlight
- fans, temperatures, etc
- enabling advanced device features via _OSC (power management, etc)
- probably tons more that i forgot


You can absolutely route interrupts to userspace

Actually, I manage quite well without ACPI on single core machines.



Wrong. Many of these use fixed addresses, and when they don't they can be detected by scanning a limited number of addresses. Also, when serial ports reside on expansion cards, ACPI has no idea. And ACPI cannot tell you if there is a functional PS/2 keyboard or mouse.



Not needed. PCI has it's own means of enumerating devices that is far superior to ACPI, and more correct too. USB resides on PCI, so no idea why ACPI would benefit USB.



Memory is delivered by BIOS or UEFI, not ACPI. I do not support hot plug.



I see no reason why I would want to support power management, but yes, if you want to support power management, ACPI would be of great help.



The memory map is supplied by BIOS/UEFI, not ACPI.



Yes, but I don't care about power management.



I don't think so. ACPI has no idea which keyboard you plugged in.



Most of these are documented in chipsets.



Maybe possible, but you don't want to do it. For one, the interrupt might not even happen in the process where ACPI is mapped.

I'm sorry rdos, there's just so much ignorance in your response, I'm just going to let you live with it

True and all, but probing for hardware is generally not a good idea and destined to go badly.

ACPI doesn't enumerate PCI devices. It enumerates non-PCI devices on other buses (like ISA). Of course it doesn't attempt to supersede PCI.

Not talking about enumerating USB, but rather ACPI will help us know what MMIO regions and interrupts USB uses. This is very important for device resource management.

If you did support ACPI, you would be able to support hot plug. Saying that is basically saying "because I don't want hot plug, nobody needs it".

Huh? Without power management, companies using your OS are literally throwing money away. Power management is crucial to conserving on costs in large servers. And on laptops. A laptop without power management would be utterly miserable to use. Heck, even Linux which does support power management is barely tolerable on laptops at times because of it's poor power management policies.

The FW memory map does not specify who owns what memory range. That's important for OS resource management / allocation. Heck, you'd be lucky if the memory even shows MMIO.

I still can't believe that.

Read here: https://wiki.ubuntu.com/Hotkeys/Architecture and here: https://wiki.gentoo.org/wiki/ACPI/ThinkPad-special-buttons

But ACPI makes this much simpler.

I'm not sure what you mean. What do you mean by "the interrupt might not even happen in the process where ACPI is mapped"?

Agreed, but everybody did this when ISA was a thing, so as long as you only probe documented IO ports I don't think it's a problem.



I generally let BIOS assign MMIO, like PCI bars. This works on most hardware, but I agree that some BIOSes will not do this correctly, or will leave unused devices unmapped. Therefore, since I don't do MMIO mapping, I don't need to know where the MMIO regions are. After all, they will not be returned as usable memory by BIOS.



Perhaps, but not even Linux has succeeded in making this work properly, so why would a hobby-OS maker? I think it's just a waste of time since so many devices have broken power-management implementations. Better to work on making things work in full-power mode than not working at all.

Still, I do support CPU power management, but in the form of specific AMD & Intel implementations since ACPI generally would typically not supply adequate methods.



Perhaps, if your motherboard has proper ACPI objects.



When you run ACPI in user mode it would be mapped in a private address space just like any other application. You cannot route an interrupt to the user mode ACPI app if another app is running.

OTOH, if you map ACPI at a fixed address in every process, then it would be a bit simpler.

9front gets away with just reading the ACPI tables, not interpreting. It does it in kernel space though.


The top diagram at the Ubuntu link shows the keyboard not connected to ACPI. It's entirely possible the Linux kernel synthesizes events in its ACPI subsystem for certain keys. It's also possible the Thinkpad hardware creates ACPI events for certain keys where a USB or actual PS/2 keyboard might be a different question entirely. Note the platform-specific THINKPAD_ACPI kernel option at the Gentoo link.