[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704271436.27353.Martin@lichtvoll.de>
Date: Fri, 27 Apr 2007 14:36:26 +0200
From: Martin Steigerwald <Martin@...htvoll.de>
To: suspend2-devel@...ts.suspend2.net
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Adrian Bunk <bunk@...sta.de>, Nick Piggin <npiggin@...e.de>,
Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Con Kolivas <kernel@...ivas.org>, Pavel Machek <pavel@....cz>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend2 merge
Am Mittwoch 25 April 2007 schrieb Linus Torvalds:
> And that's a *fundamental* problem. If the STD people cannot even
> realize that they have less to do with "suspend" than to "reboot", how
> do you ever expect them to get anything to work, and not affect other
> things negatively?
>
> Yeah, I'm down on it. I'm down on it because every person involved with
> the whole STD thing seems to have basically zero taste, and a total
> inability to work with anybody else.
Hello Linus!
I am no kernel developer. But I understand what you are trying to tell
here.
I agree that suspend to ram and snapshot should be handled differently by
drivers. And unlike schedulers - whether it be I/O or process related
ones - I think it should be quite easy to settle and decide on *one*
implementation for each feature. It least it doesn't look as difficult as
deciding on a scheduler which works for all the different workloads to
me.
I do not believe that the reasons preventing this to happen until now are
of pure technical nature.
I think snapshotting is a very important feature. I would patch it into my
kernels if it was removed. But then I am using suspend2 anyway.
Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists