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.

AndrewAPrice wrote: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.

rdos wrote: 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

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

You can absolutely route interrupts to userspace

8infy wrote:

rdos wrote: 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.

8infy wrote: 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.

8infy wrote: - 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.

8infy wrote: - memory, cpu hotplug/unplug

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

8infy wrote: - 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.

8infy wrote: - 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.

8infy wrote: - battery stats (percentage, charging/discharging, etc)
- AC adapter status

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

8infy wrote: - keyboard fn+X shortcuts and other OEM-defined keys

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

8infy wrote: - backlight
- fans, temperatures, etc

Most of these are documented in chipsets.

8infy wrote: 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.

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

rdos wrote: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.

rdos wrote: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.

rdos wrote: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.

rdos wrote: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".

rdos wrote: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.

rdos wrote: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.

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

I still can't believe that.

rdos wrote: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

rdos wrote:Most of these are documented in chipsets.

But ACPI makes this much simpler.

rdos wrote: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"?

nexos wrote: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.

nexos wrote: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.

nexos wrote: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.

nexos wrote:

rdos wrote:Most of these are documented in chipsets.

But ACPI makes this much simpler.

Perhaps, if your motherboard has proper ACPI objects.

nexos wrote:

rdos wrote: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.

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

nexos wrote:

rdos wrote: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.