Messages in this thread | | | From | "Moore, Robert" <> | Subject | RE: [ACPI] ACPI mentioned on lwn.net/kernel | Date | Fri, 25 Jan 2002 07:42:25 -0800 |
| |
And I'll add my comments about so-called "bloat".
Given that the MS VC compiler consistently generates IA-32 code that is over 30% smaller than GCC, I would have to say that Linux would benefit far more by directing all of the energy spent complaining about code size toward optimizing the compiler.
Bob
> -----Original Message----- > From: Therien, Guy [mailto:guy.therien@intel.com] > Sent: Thursday, January 24, 2002 6:16 PM > To: Grover, Andrew; 'lwn@lwn.net' > Cc: Acpi-linux (E-mail); 'linux-kernel@vger.kernel.org' > Subject: RE: [ACPI] ACPI mentioned on lwn.net/kernel > > > I'll add that contrary to your statement, EVERY other OS with > ACPI support > has it in their kernel. > Since Linux APM support calls the APM BIOS, which is not > easily changed, and > ACPI calls AML that you can capture and change to fix any problems > discovered using available tools, I'd say you were off with > the statement > about "an interpreter that can run arbitrary, closed source > code" also. You > can't "configure and dump" if you want runtime configuration and power > management. If you need more info ask on or off the list. > Regards, > ACPIGuy > > -----Original Message----- > From: Grover, Andrew [mailto:andrew.grover@intel.com] > Sent: Thursday, January 24, 2002 5:30 PM > To: 'lwn@lwn.net' > Cc: Acpi-linux (E-mail); 'linux-kernel@vger.kernel.org' > Subject: [ACPI] ACPI mentioned on lwn.net/kernel > > > 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 > > > _______________________________________________ > Acpi-devel mailing list > Acpi-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acpi-devel > > _______________________________________________ > Acpi-devel mailing list > Acpi-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acpi-devel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |