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

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

[Yu, Luming]

> > > that would be a kernel command line option to do the same thing.
> > > ACPI_STRICT=ON?
> > 
> > It is unfeasible.
> 
> Care to elaborate?

1. A kernel option such as ACPI_STRICT=ON will mess up ACPI CA code at
run-time.
For example, a small change to ACPI interpreter without strict
regression test could break
other part of ASL codes wich comply to ACPI spec. 

2. How to coordinate various workarounds which could be conflicted with
each other?

--Luming


-------------------------------------------------------
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\x1356&alloc_id438&op=click

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

[Len Brown]

You must have something specific in mind, b/c I have a more
simple-minded view.  There are two modes

1. default
all workarounds in place (there actually are not very many)
minimum pedantic warnings
users and distros expected to use this mode

2. acpi=strict
all workarounds excluded
maximum pedantic warnings
OEMs, testers, and ACPI developers expected to use this mode.

This is selected at run-time by absence or presence of acpi=strict.
If there is a case where something can't really can't be turned on and
off at run time (the case you're worrying about), then we simply leave
it the way it is now -- always on.

On Thu, 2004-02-12 at 01:32, Yu, Luming wrote:
> 1. A kernel option such as ACPI_STRICT=ON will mess up ACPI CA code at
> run-time.
> For example, a small change to ACPI interpreter without strict
> regression test could break
> other part of ASL codes wich comply to ACPI spec. 

The only regression test we us today is to ship changes to the community
and see if systems run better or run worse.  I don't see this changing.

> 2. How to coordinate various workarounds which could be conflicted with
> each other?

exactly the same way we do today.




-------------------------------------------------------
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

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

[Cagle, John (ISS-Houston)]

From: Bruno Ducrot
> On Wed, Feb 11, 2004 at 11:33:16PM -0600, Cagle, John 
> (ISS-Houston) wrote:
> > From: Yu, Luming [mailto:luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> > > 
> > > > 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.

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.

Regards,
John

-----------------------------
John Cagle  john.cagle-VXdhtT5mjnY@public.gmane.org
HP Distinguished Technologist
ProLiant Software Development
  http://www.hp.com/linux/
  Hewlett-Packard Company


-------------------------------------------------------
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\x1356&alloc_id438&op=click

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

[Bruno Ducrot]

On Thu, Feb 12, 2004 at 06:08:41PM -0600, Cagle, John (ISS-Houston) wrote:
> From: Bruno Ducrot
> > On Wed, Feb 11, 2004 at 11:33:16PM -0600, Cagle, John 
> > (ISS-Houston) wrote:
> > > From: Yu, Luming [mailto:luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> > > > 
> > > > > 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

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

[Stefan Seyfried]

On Fri, Feb 13, 2004 at 01:50:43AM +0100, Bruno Ducrot wrote:
 
> The 'toshiba return bug' is something like that:
> 
> Method(FOO) {
> 	return (0)
> }
> 
> Method(BAR) {
> 	FOO()
> }
> 
> If ACPI is pedantic, BAR return nothing.

Well, but it is a bug, so it _should_ fail with "acpi=strict", shouldn't it?
If "acpi=strict" is omitted, the bug can be worked around and the buyers of
this crap can be happy.
-- 
Stefan Seyfried



-------------------------------------------------------
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

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

[Cagle, John (ISS-Houston)]

From: Yu, Luming [mailto:luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> 
> > that would be a kernel command line option to do the same thing.
> > ACPI_STRICT=ON?
> 
> It is unfeasible.

Care to elaborate?


-------------------------------------------------------
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\x1356&alloc_id438&op=click

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

[Bruno Ducrot]

On Wed, Feb 11, 2004 at 11:33:16PM -0600, Cagle, John (ISS-Houston) wrote:
> From: Yu, Luming [mailto:luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> > 
> > > 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?

-- 
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

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

[Yu, Luming]

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

It is unfeasible.


-------------------------------------------------------
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\x1356&alloc_id438&op=click

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

[Cagle, John (ISS-Houston)]

On Wednesday, February 11, 2004 10:37 AM, Len Brown wrote:
> CONFIG_ACPI_STRICT_COMPLIANCE seems to be a good choice for the config
> option.  Disabled by default, enabled by OEMs for testing their
> platforms.
> 
> Right now, CONFIG_ACPI_RELAXED AML would be replaced by this. 
>  This will
> fix the issue that RELAXED_AML is not currently enabled by default.
> 
> We have some warnings and workarounds that gum-up various dmesg that I
> think we can put under this umbrella also.

I agree.  This should make a lot of users happy, since the distro's will
work out-of-the-box without modification (at least on those machines
with known workarounds implemented in the ACPI driver), yet the OEMs can
still test for strict compliance by recompiling the kernel.  Better than
that would be a kernel command line option to do the same thing.
ACPI_STRICT=ON?

Regards,
John


-------------------------------------------------------
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\x1356&alloc_id438&op=click

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

[Len Brown]

On Wed, 2004-02-11 at 13:04, Cagle, John (ISS-Houston) wrote:

> I agree.  This should make a lot of users happy, since the distro's will
> work out-of-the-box without modification (at least on those machines
> with known workarounds implemented in the ACPI driver), yet the OEMs can
> still test for strict compliance by recompiling the kernel.  Better than
> that would be a kernel command line option to do the same thing.
> ACPI_STRICT=ON?

I think you're right.  If STRICT added code, then a re-build would be
appropriate, b/c the default kernel shouldn't be burdened with extra
code for validation or compliance testing.  However, STRICT would
generally disable code -- so we might as well make it accessible by
using a boot option instead of a build option.  Say...

acpi=strict
  Disable workarounds in Linux for platforms that are not
  strictly ACPI compliant.  This may cause additional warnings
  or cause your system not to boot.


if (acpi_strict)
	a compliance check or warning that is known to fail
	on some systems.

if (!acpi_strict)
	a workaround that is known to be necessary
	on some non-compliant systems, eg. RELAXED_AML

-Len




-------------------------------------------------------
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

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

[Pavel Machek]

Hi!

> > think we can put under this umbrella also.
> 
> I agree.  This should make a lot of users happy, since the distro's will
> work out-of-the-box without modification (at least on those machines
> with known workarounds implemented in the ACPI driver), yet the OEMs can
> still test for strict compliance by recompiling the kernel.  Better than
> that would be a kernel command line option to do the same thing.
> ACPI_STRICT=ON?

You know how OEMs test their hardware? They stick distro
CD in, and if it boots, it must be okay :-(.
At least command line option would be good, we can't
really expect oems to recompile.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
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