Re: Working around bugs in ACPI BIOS [was Re: DSDT in initrd]

[Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>]

On Sun, May 18, 2003 at 11:34:05PM +0200, Pavel Machek wrote:
> Hi!
> 
> > I must admit I'm really torn. If there were 2-3 little AML problems that
> > if we worked around them, a horde of machines would start working, then
> > I think we would do that, but my sense is that there are many more ways
> > a DSDT can be broken, and that implementing workarounds for all of them
> > would cause other systems to fail. Maybe some of the people who have
> > fixed their DSDTs can comment on the scope of bugs out there.
> 
> I believe policy should be "if it can't possibly break anyone".
> 
> AML functions not returning value can be safely replaced with
> returning 0; uninitialized variables can also be initialized with
> 0. Both should be safe, and we should printk() loudly in both cases.
> 

o relax operational region checking (not so trivial as it sound like,
  and may be done at acpi init stage imho),
o Store(Local0, Local0) is a Noop,
o allow return statements to be propageted to the calling method if the
  caller is known to return 'something' (either because it is a reserved
  method known to return something, or because it return
  something in other code path),
o mutex mis-use.

others?

All of them could be a separate kernel options, and cry when
possible (not handled by acpi debug option).

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge