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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:33 EST