ACPI mentioned on lwn.net/kernel

ACPI mentioned on lwn.net/kernel

[Grover, Andrew]

Hi Jonathan,

As longtime subscribers to acpi-devel know, this seems to come up every few
months, but the criticisms mentioned in this week's lwn.net kernel
development summary (http://lwn.net/2002/0124/kernel.php3) prompt me to
respond, lest my silence be taken for capitulation. ;-)

The concerns seem to be summed up when the article says, "ACPI brings
substantial amounts of kernel bloat, reliability worries, and security
concerns." Let me respond to each of those in reverse order:

1) Security concerns
- I think you mistook some kernel developers' off the cuff comments about
this as being real concerns, rather than trolling me (which is apparently
frightfully easy ;-). ACPI is only concerned with power management and
configuration. It has nothing to do with digital rights management, and that
phrase does not appear anywhere in the 481 page ACPI 2.0 specification. The
word "security" appears only twice.

2) Reliability
- One of ACPI's design goals was actually to reduce the OS's susceptibility
to bad BIOSs, compared to APM. OSs using APM suffer because they must call
into the BIOS -- relinquish control completely -- to perform power
management. Under ACPI this is not the case. For example, to get the current
battery status, the steps the OS must perform are defined by the BIOS.
However, since they are performed by the OS, the OS in fact gains visibility
into the process, and does not ever relinquish control to the BIOS.

3) Bloat
- Optimizing for size (or the various unloading schemes) should wait until
the codebase stabilizes. We're still adding major pieces of functionality.
- 100K really isn't that much, compared to other kernel modules (determined
via "size *.o"), or compared to memory installed on most machines these
days.
- Bloat is compiler-dependent. Compiling the interpreter with MSVC instead
of GCC resulted in a ~40% size decrease.

Anyway, looking towards the future...

Our next release will have preliminary support for PCI IRQ routing via ACPI
(which should solve Jes's problem), along with a complete rewrite of the
ancillary drivers to adopt the new Linux 2.5 driver model. When it is ready
(target: Jan 31st) I'll post on both acpi-devel and linux-kernel. My hope
is, the more people gain familiarity of Linux's ACPI code by testing and
helping in its development, the more we all can accept it on its merits, and
start improving Linux's PnP and power management by using the improved
functionality ACPI provides.

Regards -- Andy


----------------------------
Andrew Grover
Intel/MPG/Mobile Arch Lab
andrew.grover@intel.com

Re: ACPI mentioned on lwn.net/kernel

[Jonathan Corbet]

Hi, Andy,

> As longtime subscribers to acpi-devel know, this seems to come up every few
> months, but the criticisms mentioned in this week's lwn.net kernel
> development summary (http://lwn.net/2002/0124/kernel.php3) prompt me to
> respond, lest my silence be taken for capitulation. ;-)

I'm sorry if you, or the other Linux ACPI developers, felt attacked by what
was written - that certainly wasn't the intent.  Everything that appeared
in LWN had to do with the ACPI specification, and not any particular
implementation.  I don't doubt that I could have written it in a clearer,
more even-handed way.

It may well be that the concerns over ACPI are overblown.  It is true,
however, that the concerns exist and are widely shared.  It would be
worthwhile to have a discussion on why people shouldn't worry.  What
controls are there on the things AML code can do?  What reasons are there
to expect that ACPI code will be more reliable than any other sort of BIOS
code? 

Increasingly, it seems that it will not be possible to use modern hardware
without ACPI.  So, in a sense, the point will be moot.  Certainly it is
only a good thing that Linux has a high-quality ACPI implementation in the
works, so that users will have the option to use it.  I expect that most
will happily run it and look no further.  

But that doesn't change the fact that a lot of people do not like the ACPI
standard.  There is some selling yet to be done if that dislike is to be
overcome. 

jon

Jonathan Corbet
Executive editor, LWN.net
corbet@lwn.net

Re: ACPI mentioned on lwn.net/kernel

[Alexander Viro]

On Fri, 25 Jan 2002, Jonathan Corbet wrote:

> Increasingly, it seems that it will not be possible to use modern hardware
> without ACPI.  So, in a sense, the point will be moot.  Certainly it is
> only a good thing that Linux has a high-quality ACPI implementation in the
> works, so that users will have the option to use it.  I expect that most
> will happily run it and look no further.  
> 
> But that doesn't change the fact that a lot of people do not like the ACPI
> standard.  There is some selling yet to be done if that dislike is to be
> overcome. 

Well, let's hope that when x86-64 comes out, it will go with saner chipsets.
Pity that it hadn't happened years ago - world without Itanic would certainly
be a nicer place...

Re: ACPI mentioned on lwn.net/kernel

[Pavel Machek]

Hi!

> > Increasingly, it seems that it will not be possible to use modern hardware
> > without ACPI.  So, in a sense, the point will be moot.  Certainly it is
> > only a good thing that Linux has a high-quality ACPI implementation in the
> > works, so that users will have the option to use it.  I expect that most
> > will happily run it and look no further.  
> > 
> > But that doesn't change the fact that a lot of people do not like the ACPI
> > standard.  There is some selling yet to be done if that dislike is to be
> > overcome. 
> 
> Well, let's hope that when x86-64 comes out, it will go with saner chipsets.
> Pity that it hadn't happened years ago - world without Itanic would certainly
> be a nicer place...

Can you describe pitfalls to avoid, and mail that to discuss@x86-64.org? 
AMD *is* listening.
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: ACPI mentioned on lwn.net/kernel

[Alan Cox]

> battery status, the steps the OS must perform are defined by the BIOS.
> However, since they are performed by the OS, the OS in fact gains visibility
> into the process, and does not ever relinquish control to the BIOS.

It has task file IDE access. It is capable of being abused for that or more.
Intent doesnt come into it. Its no different to the current BIOS SMM
situation. 

Alan

Re: [ACPI] Re: ACPI mentioned on lwn.net/kernel

[Patrick Mochel]

On Fri, 25 Jan 2002, Alan Cox wrote:

> > battery status, the steps the OS must perform are defined by the BIOS.
> > However, since they are performed by the OS, the OS in fact gains visibility
> > into the process, and does not ever relinquish control to the BIOS.
> 
> It has task file IDE access. It is capable of being abused for that or more.
> Intent doesnt come into it. Its no different to the current BIOS SMM
> situation. 

That's not his point. ACPI is doing what the BIOS tells us, not asking the 
BIOS to do something for is. That's not a Good Thing, but it's Better. 

Unless you're proactive about scanning BIOS routines for power mgmt,
verifying tables, and analyzing AML before you use it, you won't know 
something is wacky until it bites you. 

With AML, at least you have the freedom to pinpoint the problem and 
overridde it, either by modifying the table yourself, or providing a new 
one(*).

I'm a big ACPI pundit, and disagree with many aspects of the spec and 
implementation. But, a) we're stuck with it and b) it's a lot better in 
many aspects than previous things, including the ability to catch and work 
around problems rather than just punting on them.

	-pat

(*) Aside from any potential copyright infringement on the tables 
themselves. But, it is theoretically possible to override the DSDT with 
one provided at runtime. So, if someone finds a problem with Company X, 
Model Y's AML, they can go to acpi.sf.net and download a fixed table, run 
a utility to put it in the early init scripts, reboot and be safe. 
Hypothetically. 

Re: [ACPI] Re: ACPI mentioned on lwn.net/kernel

[Alan Cox]

> (*) Aside from any potential copyright infringement on the tables 
> themselves. But, it is theoretically possible to override the DSDT with 

Criminal liability under the DMCA and five years in jail too, along with
having your SF account pulled and losing your ISP access at the first
suggestion of copyright issues - and since you posted that email you are
clearly not doing so by accident.

Its *no* different. In fact since AML can be used to hit chipset ports to
trap into SMM mode its identical

Re: [ACPI] Re: ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

Alan Cox wrote:
> > (*) Aside from any potential copyright infringement on the tables 
> > themselves. But, it is theoretically possible to override the DSDT with 
> 
> Criminal liability under the DMCA and five years in jail too, along with
> having your SF account pulled and losing your ISP access at the first
> suggestion of copyright issues - and since you posted that email you are
> clearly not doing so by accident.

Fortunately he was citing a legitimate purpose: to workaround ACPI table
bugs.  Perhaps some judges favour legitimacy while other ones favour
corruption; choose your judges wisely :-)

> Its *no* different. In fact since AML can be used to hit chipset ports to
> trap into SMM mode its identical

Except that because we can change the tables, or detect certain access
sequences, we have the possibility to _not_ hit the chipset ports to
trap into SMM mode.  It's much harder to do this with BIOS routines (but
not impossible, just harder).

Until they reduce all the AML to single port accesses which do nothing
except call SMM mode.  That takes us right back to the APM problems ;-)

-- Jamie

Re: [ACPI] Re: ACPI mentioned on lwn.net/kernel

[David Weinehall]

On Sat, Jan 26, 2002 at 03:37:03AM +0000, Jamie Lokier wrote:
> Alan Cox wrote:
> > > (*) Aside from any potential copyright infringement on the tables 
> > > themselves. But, it is theoretically possible to override the DSDT with 
> > 
> > Criminal liability under the DMCA and five years in jail too, along with
> > having your SF account pulled and losing your ISP access at the first
> > suggestion of copyright issues - and since you posted that email you are
> > clearly not doing so by accident.
> 
> Fortunately he was citing a legitimate purpose: to workaround ACPI table
> bugs.  Perhaps some judges favour legitimacy while other ones favour
> corruption; choose your judges wisely :-)

I doubt that working around bugs is allowed either; one could argue that
both region-coding and CSS are bugs disabling me from seeing particular
DVD's and for sure that new CD-protection scheme is a bug, considering
the "CD":s they produce don't even qualify as such according to
Phillips(?)


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </