From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Add support to resume swsusp from initrd
Date: Tue, 07 Dec 2004 11:39:57 +0000 [thread overview]
Message-ID: <1102419597.13483.33.camel@tyrosine> (raw)
In-Reply-To: <20041207094439.GC1469@elf.ucw.cz>
On Tue, 2004-12-07 at 10:44 +0100, Pavel Machek wrote:
> > Ok, how does this one look? (applies on top of the __init patch from
> > last time)
>
> It looks way better than last time :-).
Excellent.
> > -
> > +extern dev_t swsusp_resume_device;
> >
> > static int noresume = 0;
> > char resume_file[256] = CONFIG_PM_STD_PARTITION;
>
> Move it to include/linux/suspend.h
swsusp_resume_device? Ok.
> > @@ -223,6 +224,18 @@
> >
> > pr_debug("PM: Reading pmdisk image.\n");
> >
> > + if (swsusp_resume_device) {
> > + /* We want to be really sure that userspace isn't touching
> > + anything at this point... */
> > + if (freeze_processes()) {
> > + goto Done;
> > + }
> > +
> > + /* And then make sure that we have enough memory to do the
> > + resume */
> > + free_some_memory();
> > + }
> > +
> > if ((error = swsusp_read()))
> > goto Done;
> >
>
> This should not be conditional.
Yeah, I wondered about that, but didn't want to change behaviour.
> > + dev_t (res);
>
> Why the ()s?
I have absolutely no idea. Copy and paste error, I think.
> > + p = memchr(buf, '\n', n);
> > + len = p ? p - buf : n;
> > +
> > + if (sscanf(buf, "%u:%u", &maj, &min) == 2) {
> > + res = MKDEV(maj, min);
> > + if (maj == MAJOR(res) && min == MINOR(res)) {
>
> You mkdev, than test that MKDEV worked? Could you add a comment why
> its needed?
That's just cut and pasted from name_to_dev_t - I assumed there was some
subtlety going on there.
> So... if userspace echos "0:0" into resume file, you attempt to do the
> resume, and oops the kernel?
Whoops, good catch.
> Why not doing name_to_dev_t,
> unconditionally, while doing resume_setup? And probably kill
> CONFIG_PM_STD_PARTITION; I do not like idea of kernel automagically
> trying to resume without anything on command line anyway.
Ok, sounds fine.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2004-12-07 11:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-05 20:48 Matthew Garrett
2004-12-05 21:12 ` Pavel Machek
2004-12-05 21:21 ` Matthew Garrett
2004-12-05 21:29 ` Pavel Machek
2004-12-05 21:42 ` Matthew Garrett
2004-12-05 21:49 ` Pavel Machek
2004-12-06 10:02 ` Stefan Seyfried
2004-12-05 21:18 ` Pavel Machek
2004-12-06 23:15 ` Matthew Garrett
2004-12-07 9:44 ` Pavel Machek
2004-12-07 11:39 ` Matthew Garrett [this message]
2004-12-07 11:46 ` Pavel Machek
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=1102419597.13483.33.camel@tyrosine \
--to=mjg59@srcf.ucam.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®