OSDev.org

xeyes wrote:

Ethin wrote:

rdos wrote:Just note that ACPI is not very useful anymore.

... What? Unless ACPI recently got superseded by something better, its still pretty much required and very useful. Mind pointing me to its successor? Clearly it has one if its "not very useful anymore".

While they are closely related, there are still some differences between current and useful, and also, between ACPI and AML.

True. Parsing ACPI tables is easy and still useful. It's the AML part that is questionable in most cases and that needs a huge driver of several megabytes. The AML code often is broken too, creating faults in the AML initialization when you use ACPICA. Both Windows and Linux have very tolerant AML parsers that can handle severely broken AML code, but ACPICA doesn't.

I agree with what **rdos** said here, ACPI is actually very useful if you want to build an OS that works on Modern Hardware, especially laptops since you will need Power Management to minimize battery consumption or the battery will drain very fast.

However, I don't really know why there is broken PC,AML,USB implementations, this seems quite illogic. Do you think that Windows or Linux will keep checking for the Interrupt Status of a device each ms ? This is inefficient.

I don't find AML a very huge machine language, anyone can create a parser within a few weeks and often update it for more features and better error checking.

I don't really think that the ACPI will be superseded for now nor for 10 years later, I don't seem to need something more than ACPI however we always doesn't know, I've seen forums from 2003 that predicted what is going now (x64, uefi...)

I'm going to stick with my integrated hand-written ACPI driver, I always beleive that integrating a library will make my kernel much slower.
I don't think a modern kernel will be very backward compatible, just a 64 bit kernel with APIC and ACPI requirements and maybe TPM also.

No one has answered my questions about Page/Swap/RAM files, you can find the topic in the forums main page

devc1 wrote: I don't find AML a very huge machine language, anyone can create a parser within a few weeks and often update it for more features and better error checking.

You are vastly underestimating the complexity of AML. Even Linux uses a fork of ACPICA. Not to mention firmware is often broken to the point OSes have to pretend they're Windows.

devc1 wrote: However, I don't really know why there is broken PC,AML,USB implementations, this seems quite illogic. Do you think that Windows or Linux will keep checking for the Interrupt Status of a device each ms ? This is inefficient.

Ask HW manufacturers.

Can my parser be complete using the AML Specification ? Not talking about error checking, and do you know some AML errors that happens or a reference to a list of them, it will help me alot!

-- Devc1: A developer who challenged the nature and skipped all these steps "https://wiki.osdev.org/Required_Knowledge". Remembering that I could not understand a single line of code written in osdev, it took me months to learn and implement the basics, now I'm almost done with the kernel !

I also think of converting AML Methods in my kernel ACPI namespace to x86_64 methods and execute them directly.

So if I identify for example as Windows NT 2003, will the DSDT Change to be compatible with the old version ?? And what changes ??

devc1 wrote:So if I identify for example as Windows NT 2003, will the DSDT Change to be compatible with the old version ?? And what changes ??

In order to know that, you have to decompile your AML code (acpica-tools on Linux contains a tool to do that), and check where the _OSI method is used and what impact it has.

For example, on my system _SB.PCI0._INI tests all the various Windows versions in ascending order, setting the internal variable OSYS to the year part of the the string (roughly). OSYS is defined in some operating region, and is the first variable in a really long list of internal variables. Anyway, where does it come into play? In the implementation of the _DSM for the Intel Power Engine. And honestly, after chasing this bloody variable all over the place, that is all I am prepared to say with certainty. It is also used in the implementation of _L66, which has something to do with a level-triggered GPE, and somehow the graphics adapter is involved.

The chase is complicated by the methods not getting any good name. It would appear all identifiers are limited to 4 characters, and that is not a whole lot of room for expression. Oh well...

That answers my questions, Thanks !

-- Devc1: An anonymous developer who challenged the nature and skipped all these steps "https://wiki.osdev.org/Required_Knowledge". Remembering that I could not understand a single line of code written in osdev, it took me months to learn and implement the basics, now I'm almost done with the X64 ACPI (blablabla...) kernel and heading for an entire mature Operating System.