Re: ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround forbroken DSDT)

On Thu, Feb 12, 2004 at 06:08:41PM -0600, Cagle, John (ISS-Houston) wrote:

From: Bruno Ducrot

quoted

On Wed, Feb 11, 2004 at 11:33:16PM -0600, Cagle, John 
(ISS-Houston) wrote:

quoted

From: Yu, Luming [mailto:luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 

quoted

quoted

that would be a kernel command line option to do the same thing.
ACPI_STRICT=ON?

It is unfeasible.

Care to elaborate?

How you will handle the toshiba return bug?

I'm not familiar with that specific bug, and I want to make it clear I
was not suggesting that we remove any existing workarounds.

Sorry, I should explain more, then.

I was suggesting that having a kernel command line option (to control
the strict-ness of the ACPI implementation) will make it a lot easier
for OEM's to test their AML under Linux.  Assuming, of course, that the
default behavior of the ACPI driver is "relaxed", which it is not
currently.

The 'toshiba return bug' is something like that:

Method(FOO) {
	return (0)
}

Method(BAR) {
	FOO()
}

If ACPI is pedantic, BAR return nothing.

On some implementation of the AML interpreter found on no-named OS, BAR
will return 0.  Also, if now you have

Method(BAZ) {
	DoSomething
	FOO()
	DoSomethingElse
	Return(1)
}

Then if ACPI is pedantic, the DoSomethingElse will be executed, and 1
will be returned, whereas on some no-named AML interpreter the DoSomethingElse
path will not be executed, and 0 will be returned.  Also, it's hard to
know what is exactly the intention of the BIOS writer on such ASL
statements.

It can be possible that the no-named AML interpreter fixed that
issue (I believe this is the case), whereas it do not fix others.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click