Re: [patch] i386 "General Options" - begone [take 2]

Re: [patch] i386 "General Options" - begone [take 2]

[Pavel Machek]

Hi!
> > Please don't tell people about sysrq-D, I'm going to kill that. OTOH
> > convient way is echo 4 > /proc/acpi/sleep -- that is if you have ACPI
> > enabled.
> Extract from the patch:
> -  You may suspend your machine by either pressing Sysrq-d or with
> <snip>
> +  require APM. You may suspend your machine by either pressing 
> +  Sysrq-d or with 'swsusp' or 'shutdown -z <time>' (patch for 
> 
> So it is in the original. When you kill the functionality, update the doco.

Yep, I should do that.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

[patch] i386 "General Options" - begone [take 2]

[Brad Hards]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

This patch (a minor update on one that I accidently left lkml out of the To:) 
removes the "General Options" top level config menu from the i386 build for 
2.5.20. It didn't describe what it was doing, and it contained a broad 
collection of mostly unrelated configuration options.
To replace it, you now get:
"Power management options (ACPI, APM)", which also includes software suspend.
"Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
"Executable file formats"

While moving software suspend, I also took the chance to tweak the Config.help 
entry.

To all those who don't like the expansion in top level directories - I agree, 
and have the genesis of a plan to build a more logical grouping (eg getting 
the various mass storage options together, getting the various networking 
options together, etc). One step at a time though, especially since that 
would affect multiple architectures.

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

[-- Attachment #2: config.in-03062002.patch --]
[-- Type: text/x-diff, Size: 5630 bytes --]

diff -Naur -X dontdiff linux-2.5.20-clean/arch/i386/Config.help linux-2.5.20-config-munging/arch/i386/Config.help
--- linux-2.5.20-clean/arch/i386/Config.help	Thu May 30 04:42:46 2002
+++ linux-2.5.20-config-munging/arch/i386/Config.help	Mon Jun  3 12:39:48 2002
@@ -641,7 +641,8 @@
   off or put into a power conserving "sleep" mode if they are not
   being used.  There are two competing standards for doing this: APM
   and ACPI.  If you want to use either one, say Y here and then also
-  to the requisite support below.
+  to the requisite support below. This option is also required for
+  "software suspend", see below.
 
   Power Management is most important for battery powered laptop
   computers; if you have a laptop, check out the Linux Laptop home
@@ -943,13 +944,15 @@
 
 Software Suspend
 CONFIG_SOFTWARE_SUSPEND
-  Enable the possibilty of suspendig machine. It doesn't need APM.
-  You may suspend your machine by either pressing Sysrq-d or with
-  'swsusp' or 'shutdown -z <time>' (patch for sysvinit needed). It
-  creates an image which is saved in your active swaps. By the next
-  booting the kernel detects the saved image, restores the memory from
-  it and then it continues to run as before you've suspended.
-  If you don't want the previous state to continue use the 'noresume'
+  Enable the possibility of suspending the machine. This does not 
+  require APM. You may suspend your machine by either pressing 
+  Sysrq-d or with 'swsusp' or 'shutdown -z <time>' (patch for 
+  sysvinit needed). It creates an image which is saved in your
+  active swap space. The next time the kernel is booted, the saved
+  image is detected and restored to memory. The machine then 
+  continues to run, in the same configuration as before the suspend.
+
+  If you don't want the previous state to continue, use the 'noresume'
   kernel option. However note that your partitions will be fsck'd and
   you must re-mkswap your swap partitions/files.
 
@@ -958,10 +961,12 @@
   involved in suspending. Also in this case there is a risk that buffers
   on disk won't match with saved ones.
 
-  SMP is supported ``as-is''. There's a code for it but doesn't work.
-  There have been problems reported relating SCSI.
+  SMP is supported ``as-is''. That is, there is code to support SMP
+  but doesn't work. There have also been problems reported relating to 
+  SCSI.
   
-  This option is about getting stable. However there is still some
-  absence of features.
+  This option is becoming progressively more stable. However there are
+  still some missing features, and data corruption is always a 
+  possibility.
 
   For more information take a look at Documentation/swsusp.txt.
diff -Naur -X dontdiff linux-2.5.20-clean/arch/i386/config.in linux-2.5.20-config-munging/arch/i386/config.in
--- linux-2.5.20-clean/arch/i386/config.in	Thu May 30 04:42:51 2002
+++ linux-2.5.20-config-munging/arch/i386/config.in	Mon Jun  3 13:01:16 2002
@@ -209,9 +209,30 @@
 endmenu
 
 mainmenu_option next_comment
-comment 'General options'
+comment 'Power management options (ACPI, APM)'
 
-source drivers/acpi/Config.in
+bool 'Power Management support' CONFIG_PM
+if [ "$CONFIG_PM" = "y" ]; then
+   source drivers/acpi/Config.in
+
+   dep_tristate '  Advanced Power Management BIOS support' CONFIG_APM $CONFIG_PM
+   if [ "$CONFIG_APM" != "n" ]; then
+      bool '    Ignore USER SUSPEND' CONFIG_APM_IGNORE_USER_SUSPEND
+      bool '    Enable PM at boot time' CONFIG_APM_DO_ENABLE
+      bool '    Make CPU Idle calls when idle' CONFIG_APM_CPU_IDLE
+      bool '    Enable console blanking using APM' CONFIG_APM_DISPLAY_BLANK
+      bool '    RTC stores time in GMT' CONFIG_APM_RTC_IS_GMT
+      bool '    Allow interrupts during APM BIOS calls' CONFIG_APM_ALLOW_INTS
+      bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
+   fi
+
+   dep_bool 'Software Suspend (EXPERIMENTAL)' CONFIG_SOFTWARE_SUSPEND $CONFIG_EXPERIMENTAL $CONFIG_PM
+fi
+
+endmenu
+
+mainmenu_option next_comment
+comment 'Bus options (PCI, PCMCIA, EISA, MCA, ISA)'
 
 # Visual Workstation support is utterly broken.
 # If you want to see it working mail an VW540 to hch@infradead.org 8)
@@ -260,6 +281,11 @@
    define_bool CONFIG_HOTPLUG_PCI n
 fi
 
+endmenu
+
+mainmenu_option next_comment
+comment 'Executable file formats'
+
 if [ "$CONFIG_PROC_FS" = "y" ]; then
    choice 'Kernel core (/proc/kcore) format' \
 	"ELF		CONFIG_KCORE_ELF	\
@@ -269,19 +295,6 @@
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
 
-bool 'Power Management support' CONFIG_PM
-
-dep_tristate '  Advanced Power Management BIOS support' CONFIG_APM $CONFIG_PM
-if [ "$CONFIG_APM" != "n" ]; then
-   bool '    Ignore USER SUSPEND' CONFIG_APM_IGNORE_USER_SUSPEND
-   bool '    Enable PM at boot time' CONFIG_APM_DO_ENABLE
-   bool '    Make CPU Idle calls when idle' CONFIG_APM_CPU_IDLE
-   bool '    Enable console blanking using APM' CONFIG_APM_DISPLAY_BLANK
-   bool '    RTC stores time in GMT' CONFIG_APM_RTC_IS_GMT
-   bool '    Allow interrupts during APM BIOS calls' CONFIG_APM_ALLOW_INTS
-   bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
-fi
-
 endmenu
 
 source drivers/mtd/Config.in
@@ -396,10 +409,6 @@
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-   dep_bool 'Software Suspend' CONFIG_SOFTWARE_SUSPEND $CONFIG_PM
-fi
-
 bool 'Kernel debugging' CONFIG_DEBUG_KERNEL
 if [ "$CONFIG_DEBUG_KERNEL" != "n" ]; then
    bool '  Debug memory allocations' CONFIG_DEBUG_SLAB

Re: [patch] i386 "General Options" - begone [take 2]

[Rusty Russell]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

In message <200206031318.09634.bhards@bigpond.net.au> you write:
> While moving software suspend, I also took the chance to tweak the Config.help 
> entry.

For trivial at least, please split the patches.  It makes it easy for
me and/or Linus to accept only one.

Also, please mention clearly if you obsolete a previous trivial patch...

> diff -Naur -X dontdiff linux-2.5.20-clean/arch/i386/Config.help linux-2.5.20-
config-munging/arch/i386/Config.help
> --- linux-2.5.20-clean/arch/i386/Config.help	Thu May 30 04:42:46 2002
> +++ linux-2.5.20-config-munging/arch/i386/Config.help	Mon Jun  3 12:39:48 200
2
> @@ -641,7 +641,8 @@
>    off or put into a power conserving "sleep" mode if they are not
>    being used.  There are two competing standards for doing this: APM
>    and ACPI.  If you want to use either one, say Y here and then also
> -  to the requisite support below.
> +  to the requisite support below. This option is also required for
> +  "software suspend", see below.
>  
>    Power Management is most important for battery powered laptop
>    computers; if you have a laptop, check out the Linux Laptop home

Like code, descriptions develop scar tissue when you do the "minimally
invasive" change.  Consider this classic trap-for-skimmers from the
glibc "snprintf" man page, and learn:

Return value
       These  functions  return  the number of characters printed
       (not including the trailing `\0' used  to  end  output  to
       strings).   snprintf  and vsnprintf do not write more than
       size bytes (including the trailing '\0'), and return -1 if
       the  output  was truncated due to this limit.  (Thus until
       glibc 2.0.6. Since glibc 2.1 these  functions  follow  the
       C99  standard and return the number of characters (exclud­
       ing the trailing '\0') which would have  been  written  to
       the final string if enough space had been available.)

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [patch] i386 "General Options" - begone [take 2]

[Pavel Machek]

Hi!

> This patch (a minor update on one that I accidently left lkml out of the To:) 
> removes the "General Options" top level config menu from the i386 build for 
> 2.5.20. It didn't describe what it was doing, and it contained a broad 
> collection of mostly unrelated configuration options.
> To replace it, you now get:
> "Power management options (ACPI, APM)", which also includes software suspend.
> "Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
> "Executable file formats"

Good.

> While moving software suspend, I also took the chance to tweak the Config.help 
> entry.

Please don't tell people about sysrq-D, I'm going to kill that. OTOH convient
way is echo 4 > /proc/acpi/sleep -- that is if you have ACPI enabled.

Swsusp is required for suspend-to-ram, too. I plan to fix that somehow,
however.
									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: [patch] i386 "General Options" - begone [take 2]

[Grover, Andrew]

> > "Power management options (ACPI, APM)", which also includes 
> software suspend.
> > "Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
> > "Executable file formats"

Brad,

This is a tough one because ACPI *is* power management but it is also
configuration. It is equivalent to such things as MPS table parsing, $PIR
parsing, PNPBIOS, as well as APM. The first two don't have CONFIG_ options
at the moment but they should at some point.

The only thing I can think of is a "Platform interface options" menu and
just throw all of the above in that. Any other ideas?

Regards -- Andy

Re: [patch] i386 "General Options" - begone [take 2]

[Dave Jones]

On Tue, Jun 04, 2002 at 01:59:11PM -0700, Grover, Andrew wrote:

 > This is a tough one because ACPI *is* power management but it is also
 > configuration. It is equivalent to such things as MPS table parsing, $PIR
 > parsing, PNPBIOS, as well as APM. The first two don't have CONFIG_ options
 > at the moment but they should at some point.
 > The only thing I can think of is a "Platform interface options" menu and
 > just throw all of the above in that. Any other ideas?

You seem to be halfway down the road of splitting ACPI in two already,
with the introduction of CONFIG_ACPI_HT_ONLY recently. Why not bundle
such options under a CONFIG_ACPI_INITIALISATION or the likes, and
put the rest under the power management menu as Brad suggested ?

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

RE: [patch] i386 "General Options" - begone [take 2]

[Grover, Andrew]

> From: Dave Jones [mailto:davej@suse.de] 
>  > This is a tough one because ACPI *is* power management but 
> it is also
>  > configuration. It is equivalent to such things as MPS 
> table parsing, $PIR
>  > parsing, PNPBIOS, as well as APM. The first two don't have 
> CONFIG_ options
>  > at the moment but they should at some point.
>  > The only thing I can think of is a "Platform interface 
> options" menu and
>  > just throw all of the above in that. Any other ideas?
> 
> You seem to be halfway down the road of splitting ACPI in two already,
> with the introduction of CONFIG_ACPI_HT_ONLY recently. Why not bundle
> such options under a CONFIG_ACPI_INITIALISATION or the likes, and
> put the rest under the power management menu as Brad suggested ?

CONFIG_ACPI_HT_ONLY was a concession to the fact that using ACPI for
processor discovery only was possible already, but in general an
all-or-nothing approach to ACPI is IMHO the safest bet.

So, let's assume in the very near future it becomes possible to compile a
kernel without MPS or $PIR support. Where should those config options go?
These, in addition to pnpbios, are also unneeded with ACPI. That is why I
was advocating the more general "Platform interface options" menu, so we
could have *one* place to config these and ACPI in or out, instead of having
the many different platform interface options in different logical areas.

My 2c -- Regards -- Andy

Re: [patch] i386 "General Options" - begone [take 2]

[Brad Hards]

On Wed, 5 Jun 2002 00:09, Pavel Machek wrote:
> Please don't tell people about sysrq-D, I'm going to kill that. OTOH
> convient way is echo 4 > /proc/acpi/sleep -- that is if you have ACPI
> enabled.
Extract from the patch:
-  You may suspend your machine by either pressing Sysrq-d or with
<snip>
+  require APM. You may suspend your machine by either pressing 
+  Sysrq-d or with 'swsusp' or 'shutdown -z <time>' (patch for 

So it is in the original. When you kill the functionality, update the doco.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] i386 "General Options" - begone [take 2]

[Dave Jones]

<trivial patchbot removed from Cc:>

On Tue, Jun 04, 2002 at 02:58:35PM -0700, Grover, Andrew wrote:

 > So, let's assume in the very near future it becomes possible to compile a
 > kernel without MPS or $PIR support. Where should those config options go?

Why do they need to be options ? They should be implied if CONFIG_ACPI=n
Otherwise we could build a kernel without any PCI IRQ routing, MPS
discovery etc.. I can't see the benefit of making this stuff compile
time optional other than to save a few bytes (and there are much better
places to start attacking to save space than this).

 > These, in addition to pnpbios, are also unneeded with ACPI.

As long as the target box has working ACPI tables and we don't have
to fall back to legacy tables.
 
 > That is why I
 > was advocating the more general "Platform interface options" menu, so we
 > could have *one* place to config these and ACPI in or out, instead of having
 > the many different platform interface options in different logical areas.

Can you confirm that you're not advocating a "ACPI or Legacy" approach ?
I think you're aware of the dragons that lie that way, but I want to be
sure my suspicions are unfounded.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

RE: [patch] i386 "General Options" - begone [take 2]

[Grover, Andrew]

> From: Dave Jones [mailto:davej@suse.de] 

> On Tue, Jun 04, 2002 at 02:58:35PM -0700, Grover, Andrew wrote:
>  > So, let's assume in the very near future it becomes 
> possible to compile a
>  > kernel without MPS or $PIR support. Where should those 
> config options go?
> Why do they need to be options ? They should be implied if 
> CONFIG_ACPI=n
> Otherwise we could build a kernel without any PCI IRQ routing, MPS
> discovery etc.. I can't see the benefit of making this stuff compile
> time optional other than to save a few bytes (and there are 
> much better
> places to start attacking to save space than this).

One reason is for code cleanliness. Linux's internal data structures for irq
routing and MPS stuff on i386 were not designed to handle the possibility of
multiple ways of getting this info. ACPI init gets in there and does its
thing, but it could be better architected. Making the legacy config options
removable is one way to ensure the kernel has things properly modularized
wrt this, and yes, I think someday (maybe not soon) someone *will* want to
leave out MPS support.

> Can you confirm that you're not advocating a "ACPI or Legacy" 
> approach ?
> I think you're aware of the dragons that lie that way, but I 
> want to be
> sure my suspicions are unfounded.

All I can say is using just *part* of ACPI will cause some machine,
somewhere, to not work. I want to avoid scenarios where that happens. If
there are issues with that, can we discuss them asap, perhaps now?

Regards -- Andy

RE: [patch] i386 "General Options" - begone [take 2]

[Alan Cox]

On Tue, 2002-06-04 at 22:58, Grover, Andrew wrote:
> So, let's assume in the very near future it becomes possible to compile a
> kernel without MPS or $PIR support. Where should those config options go?
> These, in addition to pnpbios, are also unneeded with ACPI. That is why I
> was advocating the more general "Platform interface options" menu, so we
> could have *one* place to config these and ACPI in or out, instead of having
> the many different platform interface options in different logical areas.

Hardware Discovery using
	PnpBIOS
	ISAPnP
	MCA
	PCI
	ACPI

IRQ Routing using
	PCI BIOS
	$PIR
	MP 1.x
	ACPI

Power Management using
	CPU idling instructions
	APM
	Direct power management
	ACPI


There are all sorts of combinations that make sense, and trying to make
them all map around ACPI makes no sense, especially once you hit non x86
platforms where the mentality is quite different about what is
associated

	

Re: [patch] i386 "General Options" - begone [take 2]

[Dave Jones]

On Tue, Jun 04, 2002 at 04:09:48PM -0700, Grover, Andrew wrote:
 
 > > Can you confirm that you're not advocating a "ACPI or Legacy" 
 > > approach ?
 > > I think you're aware of the dragons that lie that way, but I 
 > > want to be sure my suspicions are unfounded.
 > All I can say is using just *part* of ACPI will cause some machine,
 > somewhere, to not work. I want to avoid scenarios where that happens. If
 > there are issues with that, can we discuss them asap, perhaps now?

Think vendor kernel. There we want to run on ancient pre-ACPI boxes,
and super duper new box with borken/non-existant legacy tables.
So just keep in mind that compiling both into the kernel is a must have
requirement.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

RE: [patch] i386 "General Options" - begone [take 2]

[Grover, Andrew]

> From: Dave Jones [mailto:davej@suse.de] 
>  > > Can you confirm that you're not advocating a "ACPI or Legacy" 
>  > > approach ?
>  > > I think you're aware of the dragons that lie that way, but I 
>  > > want to be sure my suspicions are unfounded.
>  > All I can say is using just *part* of ACPI will cause some machine,
>  > somewhere, to not work. I want to avoid scenarios where 
> that happens. If
>  > there are issues with that, can we discuss them asap, perhaps now?
> 
> Think vendor kernel. There we want to run on ancient pre-ACPI boxes,
> and super duper new box with borken/non-existant legacy tables.
> So just keep in mind that compiling both into the kernel is a 
> must have
> requirement.

Oh. OK. Yes. No disagreement there.

-- Andy

RE: [patch] i386 "General Options" - begone [take 2]

[Alan Cox]

On Wed, 2002-06-05 at 00:09, Grover, Andrew wrote:
> All I can say is using just *part* of ACPI will cause some machine,
> somewhere, to not work.

We've established that pretty comprehensively. Any bit of ACPI causes
some machines somewhere to not work 8)

> I want to avoid scenarios where that happens. If
> there are issues with that, can we discuss them asap, perhaps now?

It may be that the IRQ routing and other bits of ACPI logic need to know
that their are dependancies. We handle that already for other legacy
stuff. If you don't have an MCA bus we don't do MCA bus enumerating. If
you don't have a PCI BIOS32 irq router we don't consider that option and
so forth. Having ACPI IRQ/Enumeration code that says if(!acpi) return
NULL isnt that demanding

Re: [patch] i386 "General Options" - begone [take 2]

[Brad Hards]

On Wed, 5 Jun 2002 06:59, Grover, Andrew wrote:
> > > "Power management options (ACPI, APM)", which also includes
> >
> > software suspend.
> >
> > > "Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
> > > "Executable file formats"
>
> Brad,
>
> This is a tough one because ACPI *is* power management but it is also
> configuration. It is equivalent to such things as MPS table parsing, $PIR
> parsing, PNPBIOS, as well as APM. The first two don't have CONFIG_ options
> at the moment but they should at some point.
>
> The only thing I can think of is a "Platform interface options" menu and
> just throw all of the above in that. Any other ideas?
"Platform interface" is fairly true, but so was "general options". Neither of 
them is an obvious description of the functionality.

One idea that comes to mind is putting the power management config options in 
a "Power Management" section, then PNPBIOS in with the other PnP stuff, and 
so on (read: don't know were to put MPS yet, and don't know what $PIR is :) I 
understand that this means breaking up the ACPI config file, but that 
shouldn't be too hard. 

The general concept is that [c,C]onfig.in should be functionality based, not 
implementation based. ACPI parsing isn't a function, it supports a whole 
range of functions, which are quite different to the user.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] i386 "General Options" - begone [take 2]

[Dave Jones]

On Wed, Jun 05, 2002 at 11:34:23AM +1000, Brad Hards wrote:

 > One idea that comes to mind is putting the power management config options in 
 > a "Power Management" section

*nod* sounds sensible 8)
 
 > then PNPBIOS in with the other PnP stuff, and 
 > so on (read: don't know were to put MPS yet, and don't know what $PIR is :)

It's an interrupt routing table.

MPS and interrupt routing are both CPU related features, so the best
place we currently have is under the CPU menu imho.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [patch] i386 "General Options" - begone [take 2]

[Brad Hards]

On Wed, 5 Jun 2002 20:29, Dave Jones wrote:
> On Wed, Jun 05, 2002 at 11:34:23AM +1000, Brad Hards wrote:
>  > One idea that comes to mind is putting the power management config
>  > options in a "Power Management" section
>
> *nod* sounds sensible 8)
>
>  > then PNPBIOS in with the other PnP stuff, and
>  > so on (read: don't know were to put MPS yet, and don't know what $PIR is
>  > :)
>
> It's an interrupt routing table.
>
> MPS and interrupt routing are both CPU related features, so the best
> place we currently have is under the CPU menu imho.
Is it fundamentally different _functionality_ to the stuff that is in "Plug 
and Play configuration" (which makes devices automatically get the right 
itnerrupts)?  [ Ignore implementation for a second - we can always solve this 
with another layer of abstraction. :-]

Of course, putting all this into the CPU menu (which is obviously a per-arch 
config.in change) would make drivers/arch/acpi/Config.in look a lot cleaner.

I'll try to work with Andy Grover off-list with this, and come up with an 
agreed position.

Rusty: This is starting to get a little non-trivial. Please drop the two 
patches I've sent. I'll get back to you later.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] i386 "General Options" - begone [take 2]

[fchabaud]

Le  5 Jui, Alan Cox a écrit :
> 
> Power Management using
> 	CPU idling instructions
> 	APM
> 	Direct power management
> 	ACPI

I agree with you that direct power management should be made possible,
because there's nothing preventing a very old i386 without any APM nor
ACPI feature in BIOS to suspend correctly on disk. By the way, in such a
case APM or APCI just disable themselves aren't they ? So IMHO swsusp
should have its own /proc way to activate but that may raise conflict
issues with ACPI states.

--
Florent Chabaud