OSDev.org

Those are good points. In particular, I hadn't considered potential hardware.
We are kind of at the mercy of the hardware developers.

JohnpaulTH wrote:We are kind of at the mercy of the hardware developers.

Well yes, if you run software on a hardware platform, you are obviously dependent on it.

nullplan wrote: what legacy devices are present (I really don't like probing unknown ports),

That's a bit of a luxury. You can use Windows (or Linux) and look in device manager or something to figure it out and then install drivers for those you want to use. It might even be described in the motherboard manual. Alternatively, you will see it through the connectors avaiable. While I can list all devices in ACPI, I don't use this information for anything.

nullplan wrote: how to power-manage (standby, reboot, power-off)

I don't think ACPI works better than tripple fault for rebooting, and I even know a few computers where the ACPI reboot function doesn't work.

nullplan wrote: how to get inputs (like power-button, lid button, temperature alerts, etc.)

The power button doesn't seem to work on all computers either, and CPU temperture can best be read directly from the CPU instead, or from the chipset.

nullplan wrote: how to do certain other things (like read AC status, read battery health info, ...),

Doesn't seem to be overly important either.

nullplan wrote: What other CPUs are present (MADT for the win)

AFAIK, I get those from the APIC table (MADT), and so this doesn't need any fancy ACPI functions at all.

Sounds like you are stuck in the past and reject/refuse to use anything that was created in the past 20-30 years.

kzinti wrote:Sounds like you are stuck in the past and reject anything that is new.

Past? ACPI is the past. It no longer provides any useful functionality once it's no longer needed for the IRQ routing and allowing your OS to pretend to be a recent Windows version. As for IRQ routing, it's perfectly possible to use IRQ detection for this. Some day I will remove it and save almost 1/2 MB of bloat that doesn't do anything useful.

Take the CPU core frequency & voltage settings as an example. These are useful for saving power but few ACPI implementations have the relevant entries to handle this. Thus, we are back to use Intel or AMD provided "processor support", or read the manuals on how it is done directly.

The original ACPI itself might be old, but the latest version of the specification (6.4) was released in January 2021. This is not old, this is new.

My point about you being stuck in the past is that you always seem to be rejecting anything that is newer or different than the original PC-AT. And I did mean stuck to the pre-ACPI days where you had to find devices yourselve and write motherboard drivers. Pardon me if I got this wrong.

nullplan wrote:

JohnpaulTH wrote:In your opinion is protected mode better than unreal mode?

Yes. Protected mode already frees you from that weird segment-based addressing real mode does. Unreal mode only gets rid of the segment limit, but you still have segment bases to deal with.

Agreed! Plus you'll be able to use protection rings (separate kernel from user-space) and use virtual addressing.

nullplan wrote:

JohnpaulTH wrote:Also is long mode better than protected mode?

Holy hell yes. In long mode, you have 16 registers rather than eight, and all of them are 64 bits wide. Protected mode limits you to one quarter the register capacity of long mode. While 16 is not as much as 32 (which for example PowerPC has), it is already enough to pass parameters entirely in registers. Many functions in long mode can be implemented entirely with registers, never needing auxiliary storage at all.

Agreed! Plus long mode frees you from segmentation entirely using flat memory model, which is a lot easier to use.

nullplan wrote:

JohnpaulTH wrote:With unreal you would be doing 16bit code (which takes less space)

I would dispute that. It very much depends on the use case.

Again, agreed! However in general real mode tends to use smaller code (but heavily depends on the usage, for example all 32 bit regs need an override byte in real mode, but in protmode there's no need. This is a completely non issue if real-mode code only using 16 bit regs).

nullplan wrote:

JohnpaulTH wrote:and have access to bios interrupts,

I would dispute that as well. It is entirely possible for parts of BIOS to be implemented in protected mode. See SeaBIOS for an instructive example. It is entirely possible that when leaving protected mode, it will restore the limits it assumes were in effect previously. So calling a BIOS function from unreal mode may very well undo unreal mode. In fact, so may interrupt handling. And suddenly unreal mode loses a lot of appeal.

Well, normally you can't access BIOS from prot-mode that's true (not many real machines use SeaBIOS). But with UEFI and legacy CSM gone, you'll have to say goodbye to BIOS services anyway.

nullplan wrote:

JohnpaulTH wrote:But I am not sure I see any advantage of long over protected mode.

Look at it this way: When changing from real to protected mode, you already need a major overhaul of your existing code. Switching to long mode at a later date means repeating that process. Why not skip the pain once and directly go to long mode? That way, you only need to overhaul your kernel once instead of twice.

That's a good point. Plus in long-mode the address space is so huge, you can do a lot of interesting things impossible in prot-mode (no need for sbrk syscall for example, you can put the data and stack segments so far away they would never clash).

Cheers,
bzt

rdos wrote:You can use Windows (or Linux) and look in device manager or something to figure it out and then install drivers for those you want to use.

Seriously? I want to write an OS that can at least stand on its own two feet, without requiring me to use a different OS to deliver life-support. What even is that mind-set? It would boil down to me creating a device tree (or similar) for each mainboard I want my stuff to run on. But ACPI is the PC version of a device tree, so may as well read it. And it has the benefit that it comes with the mainboard, so I don't need to ship it with the OS.

rdos wrote:I don't think ACPI works better than tripple fault for rebooting, and I even know a few computers where the ACPI reboot function doesn't work.

Whether or not the computer reboots on tripple fault is a decision of the mainboard. On tripple fault, the CPU will execute a "stop special cycle" or something like that, which the chipset can interpret however it wants. Most will reboot, but reportedly, some Dell mainboards will just hang. If the ACPI tables don't work, then perhaps a BIOS update is in order. At least this sort of thing can be fixed that way.

And none of that gives me access to standby or power-off functionality.

rdos wrote:The power button doesn't seem to work on all computers either, and CPU temperture can best be read directly from the CPU instead, or from the chipset.

Bravo. Now I can either read and implement ACPI once, or I can read all possible chipset documentation. I think, the former process scales better. Besides, even if the power button doesn't work, that situation is still no worse than if I did not support ACPI.

rdos wrote:Doesn't seem to be overly important either.

To you. My OS is about delivering service to the user. It is not for me to determine what services are "important", that is for the user to decide. And reading battery status can be very important if you are on battery and want to save your work before the computer turns off from loss of power.

rdos wrote:AFAIK, I get those from the APIC table (MADT), and so this doesn't need any fancy ACPI functions at all.

The MADT is an ACPI table.

kzinti wrote:Sounds like you are stuck in the past and reject/refuse to use anything that was created in the past 20-30 years.

I concur, it does look that way.

nullplan wrote:Seriously? I want to write an OS that can at least stand on its own two feet, without requiring me to use a different OS to deliver life-support. What even is that mind-set? It would boil down to me creating a device tree (or similar) for each mainboard I want my stuff to run on. But ACPI is the PC version of a device tree, so may as well read it. And it has the benefit that it comes with the mainboard, so I don't need to ship it with the OS.

Well, I don't think any of us will end up with a general-purpose OS that many desktop users will use, and so this seems rather irrelevant. Just because you know a device exists (through ACPI), doesn't mean you know how to handle it. You need a driver for it. Once you have written a few of these, you realize the extra information from ACPI doesn't do much good for the driver. For instance, serial ports are typically at some fixed IO addresses, or PCI devices (which are discovered through PCI enumeration and not ACPI). These are easily probed, both for port & IRQ. The legacy keyboard & mouse are always on the same IO port & IRQ, and so ACPI has nothing new to contribute. Floppy discs have two alternative IO ports & IRQs, and are likewise easily probed. IDE disc controllers are at fixed IO port & IRQs unless they are PCI devices (and then they are enumerated with PCI, not ACPI). ACPI is completely irrelevant for PCI devices, except if they lack MSI or MSI-X functionality, in which case you must either probe their IRQs or read them from ACPI.

nullplan wrote: Whether or not the computer reboots on tripple fault is a decision of the mainboard. On tripple fault, the CPU will execute a "stop special cycle" or something like that, which the chipset can interpret however it wants. Most will reboot, but reportedly, some Dell mainboards will just hang. If the ACPI tables don't work, then perhaps a BIOS update is in order. At least this sort of thing can be fixed that way.

I have a setting that determines if ACPI is used for reboot or tripple fault. The default is ACPI, but for some PCs I have to override it to disable ACPI reboot because it doesn't work.

nullplan wrote: And none of that gives me access to standby or power-off functionality.

I don't need that functionality.

nullplan wrote: Bravo. Now I can either read and implement ACPI once, or I can read all possible chipset documentation. I think, the former process scales better. Besides, even if the power button doesn't work, that situation is still no worse than if I did not support ACPI.

Well, if the ACPI is buggy you have no other alternatives than trying to get the BIOS manufacturer to fix the bug or use alternative methods. If you assume ACPI always works, you actually are at the mercy of the BIOS manufacturer, and those are not very keen on fixing problems that hobby-OS developers have, and so if it works on Windows it won't be fixed.

nullplan wrote: To you. My OS is about delivering service to the user. It is not for me to determine what services are "important", that is for the user to decide. And reading battery status can be very important if you are on battery and want to save your work before the computer turns off from loss of power.

What user? In my case, it's not end-users that determine what is needed & wanted, rather business decisions or my own desire to have a function.

nullplan wrote: The MADT is an ACPI table.

Certainly, but it doesn't need the ACPICA class to be decoded. You can decode it yourself and drop the big bloat.

Another thing I think you fail to realize is that many ACPIs have errors in them that will make ACPICA fault. Windows and Linux have extensive checks for this that appear to be lacking in ACPICA. This means that if you rely on ACPICA (or your own implementation if it doesn't handle all kinds of possible ACPI problems), then some PCs will simply fail to work because you get unrecoverable exceptions in the ACPI initialization code. I think this is the best argument why ACPI should be dropped, if possible.

kzinti wrote:The original ACPI itself might be old, but the latest version of the specification (6.4) was released in January 2021. This is not old, this is new.

I'm using a pretty old version of ACPICA, and when I try to use newer versions they will simply fail to work on many PCs, and so I have more or less given up on trying to use newer versions. I'd rather drop ACPI completely. Actually, I only use the ACPI driver with PCs that have an APIC, as on older hardware there simply is no point at all, and it seldom works either.

kzinti wrote: My point about you being stuck in the past is that you always seem to be rejecting anything that is newer or different than the original PC-AT. And I did mean stuck to the pre-ACPI days where you had to find devices yourselve and write motherboard drivers. Pardon me if I got this wrong.

Not everything. I have XHCI, AHCI, and HD audio drivers.

I never wrote any motherboard drivers either, but it would be fun. I don't like bloated specifications with little functionality, something ACPI and HID are excellent examples of.

I finally got into long mode, and will spend time poking around and implementing drivers.
Fun stuff!