From: Nigel Cunningham <ncunningham@clear.net.nz>
To: Pavel Machek <pavel@suse.cz>
Cc: Patrick Mochel <mochel@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] New system device API
Date: Tue, 10 Jun 2003 11:24:07 +1200 [thread overview]
Message-ID: <1055201047.2119.18.camel@laptop-linux> (raw)
In-Reply-To: <20030609231601.GE508@elf.ucw.cz>
On Tue, 2003-06-10 at 11:16, Pavel Machek wrote:
> Hi!
>
> > Can I bring up an issue a little off topic? Is it currently possible for
> > us to say 'I want to suspend X but not Y?', and if so how is it done? I
> > ask because someone recently mentioned the spinning up and down of IDE
> > during swsusp. That occurs because we can (AFAIK) only say suspend
> > everything at the moment. It would be good if we could put to sleep
> > everything except your system devices and the devices used to write
> > the
>
> Well, you need to suspend devices used to write the image, too, so you
> have state to return to after resume. You only do not want disks to
> spin down. Perhaps disk can just special-case it ("If I am going to
> swsusp, I need to save state, but do not really need to spin down").
Mmm. Sounds ugly though. Would it be fair to say we want to S5 some
devices and S3 others? Perhaps that sort of terminology might be
helpful.
>
> > image while preparing the image, and only suspend the remaining devices
> > once the image has been written. Is such a thing already implemented?
> >
> > As an aside, I've gone to a 1.0 pre series for 2.4 swsusp, so it
> > shouldn't be long before I'm working on 2.5. I've already created
> > swsusp25.bkbits.net, but nothing is in it at the moment. My intention is
> > that as I prepare the patches and Pavel says 'That looks ok', I'll add
> > them to the tree and we can ask Linus to pull from there.
>
> Well, I'm not allowed to use bitkeeper, so bk tree is not too exciting
> for me. But I can bless patches all right ;-).
That's all I need :> Is there another way that you could use?
Regards,
Nigel
next prev parent reply other threads:[~2003-06-09 23:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-07 1:18 [RFC] New system device API Patrick Mochel
2003-06-07 20:33 ` Pavel Machek
2003-06-09 16:19 ` Patrick Mochel
2003-06-09 18:42 ` Pavel Machek
2003-06-09 20:30 ` Patrick Mochel
2003-06-09 21:07 ` Pavel Machek
2003-06-09 21:15 ` Patrick Mochel
2003-06-09 21:23 ` Pavel Machek
2003-06-09 21:40 ` Patrick Mochel
2003-06-09 22:04 ` Pavel Machek
2003-06-09 23:09 ` Nigel Cunningham
2003-06-09 23:16 ` Pavel Machek
2003-06-09 23:24 ` Nigel Cunningham [this message]
2003-06-09 23:25 ` Patrick Mochel
2003-06-09 23:26 ` Pavel Machek
2003-06-09 21:32 ` Pavel Machek
2003-06-09 21:41 ` Patrick Mochel
2003-06-10 18:27 ` Jesse Pollard
-- strict thread matches above, loose matches on Subject: below --
2003-06-07 10:34 mikpe
2003-06-09 16:18 ` Patrick Mochel
2003-06-09 17:39 mikpe
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=1055201047.2119.18.camel@laptop-linux \
--to=ncunningham@clear.net.nz \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=pavel@suse.cz \
/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