[lkml]   [2006]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ 00/10] [Suspend2] Modules support.

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-04 12:06    [W:0.023 / U:37.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site