public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jos Hulzink <josh@stack.nl>
To: Dave Jones <davej@codemonkey.org.uk>,
	"Grover, Andrew" <andrew.grover@intel.com>
Cc: Robert Varga <nite@hq.alert.sk>, linux-kernel@vger.kernel.org
Subject: Re: 2.5.45 build failed with ACPI turned on
Date: Fri, 1 Nov 2002 22:21:56 +0100	[thread overview]
Message-ID: <200211012221.56346.josh@stack.nl> (raw)
In-Reply-To: <20021101194711.GB714@suse.de>

On Friday 01 November 2002 20:47, Dave Jones wrote:
> On Fri, Nov 01, 2002 at 11:37:26AM -0800, Grover, Andrew wrote:
>  > ACPI implements PM but that's not all it implements. Is making CONFIG_PM
>  > true if ACPI or APM are on a viable option? I think that would more
>  > accurately reflect reality.
>  >
>  > Or can we get rid of CONFIG_PM?
>
> I'm not sure of places that do it off the top of my head, but
> CONFIG_PM would save us having to do ugly CONFIG_APM || CONFIG_ACPI
> tests.

This seems to be true from what I have seen of the source so far.

I'm thinking....

ACPI is more than Power Management. The fact that a system supports ACPI does 
not mean that the user wants to use power management. On the other hand, I 
see no reason why a user does NOT want a system to auto poweroff, and sleep 
and suspend are easy to configure in BIOS, or by linux tools. (Does Linux 
take over the BIOS settings for suspend & sleep ? Don't use them, so 
donnow....) What I wanna say: I think it is okay if CONFIG_PM is replaced by 
CONFIG_APM || CONFIG_ACPI

Other issue: Are ACPI and APM not mutually exclusive ? If so, I would propose 
a selection box: <ACPI> <APM> <none> with related options shown below. Hmzz.. 
there the issue of the fact that ACPI is more than power management shows up 
again.

And well... CONFIG_APM || CONFIG_ACPI might look ugly to you, I think it isn't 
that bad, besides, you gain a lot from the configuration side. IMHO 
configuring the kernel has become hard enough with the new input layer 
already :( Maybe it is time for a "[ ] show expert options" in the 
configuration tool... 

Jos


  reply	other threads:[~2002-11-01 20:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-01 19:37 2.5.45 build failed with ACPI turned on Grover, Andrew
2002-11-01 19:47 ` Dave Jones
2002-11-01 21:21   ` Jos Hulzink [this message]
2002-11-01 20:31     ` Dave Jones
2002-11-02 20:11       ` Jos Hulzink
2002-11-06  0:38         ` Bill Davidsen
2002-11-06 15:08           ` David Woodhouse
2002-11-06 16:33             ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2002-10-31 19:45 Robert Varga
2002-11-01 19:02 ` Jos Hulzink
2002-11-01 19:12 ` Jos Hulzink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200211012221.56346.josh@stack.nl \
    --to=josh@stack.nl \
    --cc=andrew.grover@intel.com \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nite@hq.alert.sk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox