From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Nigel Cunningham <nigel@suspend2.net>
Subject: Re: [ 01/23] [Suspend2] Make workqueues freezeable.
Date: Fri, 27 Jan 2006 00:17:18 +0100
User-Agent: KMail/1.9
Cc: linux-kernel@vger.kernel.org, Pavel Machek <pavel@suse.cz>
References: <20060126034518.3178.55397.stgit@localhost.localdomain> <20060126034527.3178.99591.stgit@localhost.localdomain>
In-Reply-To: <20060126034527.3178.99591.stgit@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601270017.18773.rjw@sisk.pl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1052
Lines: 24

Hi,

On Thursday, 26 January 2006 04:45, Nigel Cunningham wrote:
> 
> Prior to this patch, kernel threads and workqueues are unconditionally
> unfreezeable. This patch reverses that behaviour, making the default
> for kernel processes to be frozen. New variations of the routines for
> starting kernel threads and workqueues (containing _nofreeze_) allow
> threads that need to run during suspend to be made nofreeze again.

This looks like "let's make everything freezable and hunt for things that
must not be frozen" kind of approach, but isn't it error-prone?  I mean,
for example, if someone creates a kernel thread that in fact must not
be frozen, but forgets to use the _nofreeze_ call, things will break for
some people and the problem will be worse than the current one,
it seems.

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