Re: Runlevel for Sleep?

Hi!

quoted

quoted

I believe 3 of them are needed - S1, S3 and S4.

It might be, but that way we are reserving all unimplemented runlevels, which 
looks really bad. I wish we could safely (for all systems) pass sth like an 
argument to the runlevel, indicating which sleep state we 're getting into.

quoted

I agree that we need to do some amount of user-level work before we go to
sleep, but I'm not sure that a runlevel is the proper way to implement
it.

My "original" idea is to use the init mechanism instead of any custom scripts 
and code, mainly just to avoid having extra binaries in our kernel.

quoted

Unless you implemented a new runlevel for every possible sleep state for
every possible platform suspend mechanism, how would pass what suspend
state you wanted to enter?

If you do that, you're certainly ACPI-specific.

quoted

You don't really want to have a different one for S1, S3, and S4 because
they are ACPI specific, both in terms of their names and what they mean.
I don't think you could create a clean, sensible solution like that, that
worked for all platforms...

Okay, we can probably forget S1 and create arch-neutral
"suspend-to-disk" and "suspend-to-ram".

IMHO you couldn't skip S1. I'm using that (in fact S3 works for me much 
worse) and I surely have to run some scripts before entering that.

We could easily agree with APM developers to have a common implementation, 
which gives the runlevel implementation an advantage. The runlevel business 
should not be ACPI specific for sure.

P. Christeas


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390