Mailinglist Archive: opensuse (4749 mails)
| < Previous | Next > |
Re: [SLE] acpi
- From: Philipp Thomas <philipp.thomas@xxxxxxxxx>
- Date: Thu, 01 May 2003 13:27:22 +0200
- Message-id: <jlv1bvoklvl3ovd8cp2cq206tfijktrqr8@xxxxxxx>
dep <dep@xxxxxxxxxxxxxxxx> [Wed, 30 Apr 2003 19:48:08 -0400]:
>okay, granted. and if the purpose of the exercise is assigning blame,
>the job is done.
You seem to be skilled in alienating people, don't you? Why do you think
that aggressively pushing your point will make the discussion any
better?
>if, however, the purpose of the exercise is getting
>suse running on customers' machines, then acpi defaulting to off,
>with documentation describing how to turn it on, would seem to be the
>right thing to do, don't you agree?
Quite frankly, no. It should stay on by default but with better
blacklists and whitelists to turn it (or at least parts) off/on where
needed. That's why
http://www.suse.de/en/private/products/suse_linux/i386/acpi.html
has this at the end:
In order to be able to expand the blacklist (as well as the
whitelist) for the kernel, we need to know on which systems the
problems occur. Therefore, please send an e-mail message to
acpi@xxxxxxxx Tell us which kernel parameter(s) worked on your
system. (Please include the output of the diagnosis tools acpidmp
and dmidecode in your message. These tools are available at
ftp.suse.com/pub/people/ak/diag.)
>the reason acpi is broken in so many places is that intel, toshiba,
>and microsoft corporation have every reason to keep the standard just
>far enough out of reach that it is not easy for other companies to
>embrace.
No, that's a nice conspiration theory but IMO doesn't hold.
Like other things thought up inside Intel, ACPI is extremely ambitious
and so complicated (the kernel needs a complete interpreter just for
ACPI) that many failed to follow the rules correctly.
It needed Intel to get reasonably good ACPI support into the kernel.
Philipp
--
Philipp Thomas work: pthomas@xxxxxxx
Development, SuSE Linux AG private: philipp.thomas@xxxxxxxxx
>okay, granted. and if the purpose of the exercise is assigning blame,
>the job is done.
You seem to be skilled in alienating people, don't you? Why do you think
that aggressively pushing your point will make the discussion any
better?
>if, however, the purpose of the exercise is getting
>suse running on customers' machines, then acpi defaulting to off,
>with documentation describing how to turn it on, would seem to be the
>right thing to do, don't you agree?
Quite frankly, no. It should stay on by default but with better
blacklists and whitelists to turn it (or at least parts) off/on where
needed. That's why
http://www.suse.de/en/private/products/suse_linux/i386/acpi.html
has this at the end:
In order to be able to expand the blacklist (as well as the
whitelist) for the kernel, we need to know on which systems the
problems occur. Therefore, please send an e-mail message to
acpi@xxxxxxxx Tell us which kernel parameter(s) worked on your
system. (Please include the output of the diagnosis tools acpidmp
and dmidecode in your message. These tools are available at
ftp.suse.com/pub/people/ak/diag.)
>the reason acpi is broken in so many places is that intel, toshiba,
>and microsoft corporation have every reason to keep the standard just
>far enough out of reach that it is not easy for other companies to
>embrace.
No, that's a nice conspiration theory but IMO doesn't hold.
Like other things thought up inside Intel, ACPI is extremely ambitious
and so complicated (the kernel needs a complete interpreter just for
ACPI) that many failed to follow the rules correctly.
It needed Intel to get reasonably good ACPI support into the kernel.
Philipp
--
Philipp Thomas work: pthomas@xxxxxxx
Development, SuSE Linux AG private: philipp.thomas@xxxxxxxxx
| < Previous | Next > |