Messages in this thread | | | From | Matthew Garrett <> | Date | Sun, 05 Dec 2004 21:42:08 +0000 | Subject | Re: [PATCH/RFC] Add support to resume swsusp from initrd |
| |
On Sun, 2004-12-05 at 22:29 +0100, Pavel Machek wrote:
> > resume_device is set by swsusp_read, which requires name_to_dev_t to be > > working. At the point where that's called, the device driver hasn't been > > loaded and we don't have the information to get the dev_t. Once the > > driver has been loaded, name_to_dev_t has already been discarded (it's > > marked __init). So we need to set resume_device somehow. > > What about move of resume_device setup somewhere sooner?
Ah - we could always set resume_device, even if there's nothing to resume. That way, it'd be set correctly for userspace later on. Ok, I think I can make that work.
> > Heh. Yes, that's no problem. A new bigdiff for -rc3 would be > > helpful. > > Hmm, I'm still on 2.6.9, but this code did not change much. I'll > generate it.
Thanks!
> > Ok. I'll look into that. The main reason I want code like this is that > > Debian use modular IDE drivers that are stored in the initrd. The disks > > won't be touched until the root file system is mounted, and we'll > > trigger the resume before then, so there shouldn't be any risk of data > > loss. At this point, there shouldn't be any userspace running other than > > a single shell script - do you think it's still a problem? > > Single shell script would probably do no harm, but then, you want this > to go into mainline, not into Debian kernel, right? ;-).
Heh.
> Actually freezing processes is good thing to do even for normal > resume. We pretty much know there are no harmfull processes running > there, but better safe than sorry.
Ok, I'll deal with that once I've got the post 2.6.10 code to work with.
Thanks! -- Matthew Garrett | mjg59@srcf.ucam.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |