Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen <ml-Y9IUUvl1dgU0Iwp8Nzs06g@public.gmane.org>]

Andi Kleen wrote:

> 
> The Intel interpreter is very strict (even with the relaxed aml option),
> microsoft is very lax. That causes problems.
> 
> But interpreter problems are usually fairly easy to fix. The
> interpreter could be probably be made even more relaxed, but the
> maintainers (Len.et.al) don't seem to want to go that path so I don't see it
> happening.  They write the code, so it works like they want it.
> 
> It would not help that much anyways.
> 
> The interpreter problems would be all easy to catch by QA
> (even without actually booting linux). And also easy to fix
> afterwards, just a bit time consuming.
> 

What about keeping the interpreter strict, but always before passing the 
DSDT to the interpreter, disassemble it and check it for problems. That 
"tester" should then be able to fix the most common problems. Then 
compile it again and pass it to the interpreter. Eventually a sort of 
intermediate language can be used that gives an easy to parse output.

Pro:
* Can fix common problems on the fly
* Can maintain a table of know defects (e.g. don't drive fan of notebook 
XXX)
* Can do all kinds of changes based upon command line options
* Parser code fast, clean and according to standard (verificatable!)
* "New" DSDT is very trustable, so less checking/conditional handling in 
rest of LL kernel code regarding ACPI
* APM -> ACPI "tranlation": write APM in ACPI-terms and get rid of APM 
code in kernel.
* Does not need to be kernel code -> easier to debug and less runtime-risk

Con:
* Boot time
* Maintenance
* Initrd size
* Development time

> The nasty problems are other logic bugs in parsing tables and interpreting
> results of methods. There doing the same thing as Windows is basically
> impossible.
> 

Why? Is that missing knowledge of what Windows does or is the Windows 
implementation too different?

> You're assuming that all interactions with ACPI are well understood.
> But it's an extremly complex system hooking into all kinds of low level
> parts of the kernel
> 
 > (snipped some explanation)

True. So maybe pre-examening is a way to keep the implementation as 
simple as it can be. You are right that having a dynamic behaviour of 
the linux-acpi is not the way to go.

So I think we need to have means to reshape the DSDT at runtime before 
interpreting it. It will definitely not catch all cases, but at least 
some of them.


Bas.





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn