On Sat, 2009-06-20 at 18:25 +0000, sten wrote: > :-) Cool! The primary reason I think this progress-bar is worthwhile > is that people have more and more RAM in their computers, and they're > doing more with them, and Ubuntu provides the assurance that their > machine state will be correctly restored when they return from > hibernation, so the hibernation image tends to be quite large; and as > most people use spinning disks, the resume process entails moving a > gigabyte or two, which is anything but instant. > > I'm not sure how the levels of kernel and pm-utils interact, but it > seems like the problem can be solved fairly simply...it's more > architecture/planning than tricky algorithm. > > 1. Either ramsize or imagesize, in kilobytes, should be stored at the end of > image creation (I think this is where/when it would go) > 1.5 I'm not sure if it's possible, but seems like it might be slightly faster > to have this information in front of the image, on the swap partition (but > this would require a kernel patch...) > 2. I'm not sure when/where it would be most efficient to convert the > kilobytes to however many units the existing (unused) progress bar, during > suspend/resume. > 4. It seems more efficient to read in the size as we build the image; when we > restore, it might be faster to just read in this number? > 5. Alternatively does kernel might have a function that returns how many > blocks/bytes/kilobytes has been restored -- if so, maybe we should use it? > 5.5 Otherwise we'll need to patch the kernel, or restore through a pipe of > some kind. This pipe is more in pm-utils land than a kernel patch. ;-) > 6. The first example that comes to mind, as an efficient way to monitor > status, is the ^\ (SIGQUIT) output of "star"....well, this is probably more > like the kernel function approach. The way "buffer" works is more pipe-like. > 6.5 I'm not sure which way is more likely to accommodate the eventual switch > to something like suspend2. > 7. the usplash code can handle things from here, one it has a maximum limit, > numbers for a progress update, and -- possibly -- touch of arithmetic to > change a big image size number into coarser-grained progress update values. > > Does this sound like it's on the right track? Regrettably, I only have > a bit of sh and C++ experience, and not nearly enough to actually write > this progress bar...But I'd love to help with prototyping and testing. >
Actually I've got a patch for this, which provides uswsusp with usplash support. Unfortunately, I keep running into an issue with uswsusp where it keeps hanging at the end of the resume process. It's possible to workaround by using Alt+SysRq+E at that part though. A patched package for Karmic is available in one of my PPAs (bugfixes). Feel free to test it and work on it if you feel up to it. -- Regards, Chow Loong Jin -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
