Re: Fix up power managment in 2.6

[Bill Davidsen]

On Thu, 4 Sep 2003, Pavel Machek wrote:

> Hi!
> 
> 
> > > >  #include "power.h"
> > > > 
> > > > -extern long sys_sync(void);
> > > > -
> > > > -unsigned char software_suspend_enabled = 0;
> > > > +unsigned char software_suspend_enabled = 1;
> > > > 
> > > >  #define __ADDRESS(x)  ((unsigned long) phys_to_virt(x))
> > > > 
> > > > ...by this you enable suspend even before system is booted. That's bad
> > > > idea. It could hurt in the past (when we had sysrq-D so swsusp), and
> > > > it may hurt again in future when battery goes low during boot.
> > > 
> > > Does it or does it not cause a problem? Look at the old software_suspend() 
> > > function - The handling of this flag was weird and non-standard. This is 
> > > cleaner. 
> > 
> > I don't want to get in the middle of this, but having a laptop decide
> > that it doesn't have enough battery to finish a boot is something which
> > happens now and again. If this change could cause data corruption where
> > the old code didn't, perhaps we could stand the overhead of moving the
> > enable to the end of the boot, or wherever would be safe.
> 
> We do not yet do suspend-to-disk on battery low, so Patrick's code is
> actually safe. Still I do not think that's good change.

I'm not sure trying to suspect during boot is a good thing to do, either.
Maybe that should wait and be enabled at user option at the end of boot.
In any case, I think avoiding data damage is higher priority than
efficiency, elegance, modularity, etc.

Beyond that I'll let you guys fight it out, I'm just worried that the new
pm is going to bite me even if I don't use suspend.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/