ACPI in userland (microkernel)

[AndrewAPrice]

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.

[rdos]

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.

[8infy]

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

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

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

You can absolutely route interrupts to userspace

[rdos]

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

This just shows your limited understanding of what ACPI is.

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

ACPI is a must for the following cases:
- discovering any devices not discoverable otherwise (ISA, PS/2, serial, anything non-pci, ...)

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.

- discovering routing/locations/ownership of devices (PCI, USB, I2C, ...) by inspecting _ADR/_PRT and similar objects

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, cpu hotplug/unplug

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

- shutting the system down, or suspending (_S1 - _S4)

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.

- managing system resources like IO, memory, etc ranges (a kernel will inspect all _CRS buffers and reserve all to prevent conflicts)

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

- battery stats (percentage, charging/discharging, etc)
- AC adapter status

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

- keyboard fn+X shortcuts and other OEM-defined keys

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

- backlight
- fans, temperatures, etc

Most of these are documented in chipsets.

You can absolutely route interrupts to userspace

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.

[8infy]

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

[nexos]

Wrong. Many of these use fixed addresses, and when they don't they can be detected by scanning a limited number of addresses.

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

Not needed. PCI has it's own means of enumerating devices that is far superior to ACPI, and more correct too.

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.

USB resides on PCI, so no idea why ACPI would benefit USB.

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.

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

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

I see no reason why I would want to support power management

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 memory map is supplied by BIOS/UEFI, not ACPI.

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.

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

I still can't believe that.

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

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

Most of these are documented in chipsets.

But ACPI makes this much simpler.

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 not sure what you mean. What do you mean by "the interrupt might not even happen in the process where ACPI is mapped"?

[rdos]

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

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.

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.

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.

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.

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.

Most of these are documented in chipsets.

But ACPI makes this much simpler.

Perhaps, if your motherboard has proper ACPI objects.

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 not sure what you mean. What do you mean by "the interrupt might not even happen in the process where ACPI is mapped"?

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.

[eekee]

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

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

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

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.