Re: [ 00/10] [Suspend2] Modules support.

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

Hi,

On Saturday 04 February 2006 10:54, Nigel Cunningham wrote:
> On Saturday 04 February 2006 19:01, Pavel Machek wrote:
> > On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> > > Hi Pavel.
> > >
> > > On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > > > [Pavel is willing to take patches, as his cooperation with Rafael
> > > > shows, but is scared by both big patches and series of 10 small
> > > > patches he does not understand. He likes patches removing code.]
> > >
> > > Assuming you're refering to the patches that started this thread, what
> > > don't you understand? I'm more than happy to explain.
> >
> > For "suspend2: modules support", it is pretty clear that I do not need
> > or want that complexity. But for "refrigerator improvements", I did
> 
> ... and yet you're perfectly happy to add the complexity of sticking half 
> the code in userspace. I don't think I'll ever dare to try to understand 
> you, Pavel :)
> 
> > not understand which parts are neccessary because of suspend2
> > vs. swsusp differences, and if there is simpler way towards the same
> > goal. (And thanks for a stress hint...)
> 
> I think virtually everything is relevant to you.

My personal view is that:
1) turning the freezing of kernel threads upside-down is not necessary and
would cause problems in the long run,
2) the todo lists are not necessary and add a lot of complexity,
3) trying to treat uninterruptible tasks as non-freezeable should better be
avoided (I tried to implement this in swsusp last year but it caused vigorous
opposition to appear, and it was not Pavel ;-))

> A couple of possible  exceptions might be (1) freezing bdevs,
> because you don't care so much about making xfs really sync and really
> stop it's activity

As I have already stated, in my view this one is at least worth considering
in the long run.

> and (2) the  ability to thaw kernel space without thawing userspace. I want
> this for eating memory, to avoid deadlocking against kjournald etc. I haven't 
> checked carefully as to why you don't need it in vanilla.

Because it does not deadlock?  I will say we need this if I see a testcase
showing such a deadlock clearly.

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/