Comment 3 for bug 379673

:-) 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.