Re: RFC 0/4: make ACPI interpret safe for suspend/resume

Hi!

quoted

[Or perhaps you want this variable to be acpi-local?]

For the memory allocating issue and semaphore issue, we actually can not
use the new system state, we can just do:
if (in_atomic() || in_interrupt())
	kmalloc(.., GFP_ATOMIC)
But this possibly will mask some real runtime errors, so we want to add
a new system state to make suspend/resume work and not break normal
process. But If new system state is a bad idea, we can make it
acpi-local.

Actually, I do not quite like new system state, but introducing new
"in_suspend()" macro would certainly be ok. We actually talked about
that one on linux-pm, just noone got around to implement it.

quoted

quoted

P.S. Did anybody know why we should freeze all processes for S3 and
S4BIOS? I checked FreeBSD code, it doesn't. I know it's safer, but if
all device drivers can freeze request to them, it's possibly not
required to me.

Freezing all processes should not be required. 

How about just make suspend/resume task as a highest priority task with
FIFO scheduler policy? 

That might do the trick for S3, but not for swsusp. Imagine normal
process holding some lock you want (for writing image to disk). You
can run on FIFO scheduler, but then you block on this lock, and
userspace process gets to run, and gets confused.
							Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl