public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@cyclades.com>
Cc: Greg KH <greg@kroah.com>,
	Dumitru Ciobarcianu <Dumitru.Ciobarcianu@iNES.RO>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] [RFC] userland swsusp
Date: Wed, 16 Nov 2005 22:35:17 +0100	[thread overview]
Message-ID: <20051116213517.GD12505@elf.ucw.cz> (raw)
In-Reply-To: <1132171051.25230.53.camel@localhost>

Hi, all!

> > > > It's also implemented in the kernel, which is exactly the wrong place
> > > > for this.  Pavel is doing this properly, why do you doubt him?
> > > 
> > > You yourself called it a hack not long ago.
> > 
> > I did, in the proud tradition of neat hacks.  It's a very nice
> > accomplishment that this even works, and I'm impressed.
> > 
> > > I'm not sure why you think the userspace is the right place for
> > > suspending.
> > 
> > If he can come up with an implementation that works, and puts stuff like
> > the pretty spinning wheels and progress bars and encryption in
> > userspace, that's great.  That stuff doesn't belong in the kerenel if we
> > can possibly help it.
> 
> I can agree with putting splash screens and userspace stuff in
> userspace. Suspend2 has had that too, since March. But the guts of
> the

Well, I'd say that having to resort to netlink is ... not quite
nice. You get all the complexity of having userspace running during
suspend, and get very little benefit.

> code is a different thing. Encryption - well, I think we're both using
> cryptoapi now, so that's more easily done in the kernel.

Its not only encryption. It is encryption, compression, support for
suspend over network, support for suspend into file. That's quite a
lot of stuff.

> > Then propose a better way to do this, if you can see one.
> 
> We've done the user interface in userspace using netlink to
> communication.
> 
> We've done storing a full image of memory by storing the page cache
> separately to the rest of the image, so that it doesn't need to have an
> atomic copy made. (Nothing that uses the page cache is running anyway).
> Having done this, we can use the memory occupied by the page cache for
> our atomic copy, and just reread the overwritten page cache pages if we
> need to cancel the suspend. Suspend2 has done this since... beta18 I
> think.

...at expense of complexity, and hooks all over the kernel. Yes, if
you modify kernel a bit, nothing will use the page cache.

Anyway, I believe we have solution for that one. See Rafael's recent
patches -- "only free as much memory as neccessary" should do the
trick, without excessive complexity.

> > > I know that Pavel and I have such different ideas about what should be
> > > done that it's not worth the effort.
> > 
> > I'm sorry that you feel this way.  I thought that after our meeting in
> > July that things were different.
> 
> I'm sorry you came away with that impression. I want to work together,
> but I'm not willing to settle for a minimalist implementation. Pavel, on
> the other hand, wanted a minimalist implementation at first. He seems to
> be changing his mind a bit now, but I'm not sure how far that will go.

Well, I do not want the complexity of two page sets. I think Rafael's
patches will provide almost equivalent functionality. Other than that,
all your features should be doable. I'm not saying I'm going to write
those patches myself, but I'll certainly not reject them just because
they are too big.
								Pavel
-- 
Thanks, Sharp!

  reply	other threads:[~2005-11-16 21:35 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-15 21:29 [RFC] userland swsusp Pavel Machek
2005-11-15 21:32 ` [linux-pm] " Greg KH
2005-11-15 22:03   ` Pavel Machek
2005-11-15 22:25 ` Dave Jones
2005-11-15 23:32   ` Pavel Machek
2005-11-15 23:40     ` Dave Jones
2005-11-16  8:56       ` Pavel Machek
2005-11-16 21:41       ` Rafael J. Wysocki
2005-11-16  4:35     ` Dumitru Ciobarcianu
2005-11-16  6:14       ` Greg KH
2005-11-16  6:00         ` Nigel Cunningham
2005-11-16 16:50           ` Greg KH
2005-11-16 19:57             ` Nigel Cunningham
2005-11-16 21:35               ` Pavel Machek [this message]
2005-11-16 21:13                 ` Nigel Cunningham
2005-11-16 22:47                   ` Pavel Machek
2005-11-16 21:53                     ` Nigel Cunningham
2005-11-23 10:16                     ` Lorenzo Colitti
2005-11-23 12:02                       ` Pavel Machek
2005-11-19  9:32           ` Rob Landley
2005-11-19 23:51             ` Pavel Machek
2005-11-18 19:36   ` Alan Cox
2005-11-18 21:18     ` Dave Jones
2005-11-18 21:20       ` Greg KH
2005-11-19 23:43       ` Pavel Machek
2005-11-20 21:48         ` Dave Jones
2005-11-20 22:09           ` Pavel Machek
2005-11-21 11:47             ` Rafael J. Wysocki
2005-11-21 14:19               ` Pavel Machek
2005-11-18 21:23     ` Arjan van de Ven
2005-11-18 22:07       ` Alan Cox
2005-11-19  4:18         ` Jesse Barnes
2005-11-19  8:44         ` Arjan van de Ven
2005-11-18 23:34     ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2005-11-16 16:10 Gross, Mark
2005-11-16 16:44 ` Greg KH
2005-11-16 20:20   ` Nigel Cunningham
2005-11-16 22:05     ` Pavel Machek
2005-11-16 21:13       ` Nigel Cunningham
2005-11-16 22:41         ` Rafael J. Wysocki
2005-11-16 22:50         ` Pavel Machek
2005-11-17 17:02       ` Olivier Galibert
2005-11-17 19:57         ` Lee Revell
2005-11-17 20:12           ` Olivier Galibert
2005-11-17 20:20             ` Lee Revell
2005-11-17 20:37               ` Dave Jones
2005-11-17 20:46                 ` Lee Revell
2005-11-17 20:59                   ` Dave Jones
2005-11-17 20:54                 ` Lee Revell
2005-11-17 21:01                   ` Dave Jones
2005-11-17 21:06                   ` Chris Wright
2005-11-17 21:14                     ` Lee Revell
2005-11-17 21:18                       ` Chris Wright
2005-11-17 21:45                         ` Diego Calleja
2005-11-17 21:09                 ` Matthew Garrett
2005-11-17 21:16                   ` Lee Revell
2005-11-17 20:47             ` Lee Revell
2005-11-16 22:10     ` Greg KH
2005-11-16 21:25       ` Nigel Cunningham
2005-11-17  7:14         ` Arjan van de Ven
2005-11-16 19:10 ` Pavel Machek
2005-11-17 16:54   ` Olivier Galibert
2005-11-17 16:44     ` Greg KH
2005-11-17 17:03       ` Patrick Mochel
2005-11-17 17:31       ` Olivier Galibert
2005-11-17 20:15       ` Jacek Kawa
2005-11-17 21:56         ` Greg KH
2005-11-18 17:41           ` Jacek Kawa
2005-11-18 23:22     ` Pavel Machek
2005-11-17 18:50 Starikovskiy, Alexey Y

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051116213517.GD12505@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=Dumitru.Ciobarcianu@iNES.RO \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=ncunningham@cyclades.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox