Re: [PATCH] Freezer / Documentation: Update freezer documentation

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, October 29, 2011, Srivatsa S. Bhat wrote:
> This patch:
>  * substitutes some obsolete references to kernel/power/process.c by
>    kernel/freezer.c
>  * mentions kernel/freezer.c as being part of the "freezer" code along
>    with the rest of the files
>  * fixes a trivial typo.
> 
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>

Applied to linux-pm/linux-next.

Thanks,
Rafael


> ---
> 
>  Documentation/power/freezing-of-tasks.txt |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
> index 38b5724..316c2ba 100644
> --- a/Documentation/power/freezing-of-tasks.txt
> +++ b/Documentation/power/freezing-of-tasks.txt
> @@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
>  either wakes them up, if they are kernel threads, or sends fake signals to them,
>  if they are user space processes.  A task that has TIF_FREEZE set, should react
>  to it by calling the function called refrigerator() (defined in
> -kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state
> +kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
>  to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
>  Then, we say that the task is 'frozen' and therefore the set of functions
>  handling this mechanism is referred to as 'the freezer' (these functions are
> -defined in kernel/power/process.c and include/linux/freezer.h).  User space
> -processes are generally frozen before kernel threads.
> +defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
> +User space processes are generally frozen before kernel threads.
>  
>  It is not recommended to call refrigerator() directly.  Instead, it is
>  recommended to use the try_to_freeze() function (defined in
> @@ -95,7 +95,7 @@ after the memory for the image has been freed, we don't want tasks to allocate
>  additional memory and we prevent them from doing that by freezing them earlier.
>  [Of course, this also means that device drivers should not allocate substantial
>  amounts of memory from their .suspend() callbacks before hibernation, but this
> -is e separate issue.]
> +is a separate issue.]
>  
>  3. The third reason is to prevent user space processes and some kernel threads
>  from interfering with the suspending and resuming of devices.  A user space
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>