Hi, On Saturday 26 August 2006 12:59, Pavel Machek wrote: > Hi! > > > I will be on vacation from tomorrow to the next Saturday (inclusive), > > without > > any Internet access. > > So you should be back by now? ;-).
I am. :-) > > In case you want to try the latest-greatest there is a series of patches at: > > > > http://www.sisk.pl/kernel/patches/2.6.18-rc4-mm1/ > > > > consisting of: > > - some 2.6.18-rc4-mm1 fixes (and a hack disabling serial console suspend), > > - some patches that have been sent for inclusion into -mm recently, > > - the "handle highmem better" patch that removes the highmem-related > > limitations of swsusp, > > - four experimental patches that make it possible to save suspend images > > to swap files. > > > > Everything up to and including swsusp-handle-highmem-better.patch has been > > tested and should work. > > ata-kconfig-fix.patch ... should go to ide people. Looks trivial, but > I'm surprised it is needed. I think this was fixed independently by Adrian Bunk. Should be in -mm already anyway. > tty-console-suspend-resume-fix.patch ... if it works for you, it is > good enough for merge. ACK. Heh, this thing was vetoed by Linus. I use it locally, because it fixes the problem for me, but it's more of a workaround than a fix. BTW, its not needed with the next one. > hack-serial-suspend.patch ... it is really a hack, but we want serial > console to work. rmk needs to sign this off, but it looks okay. ACK. I'm a bit reluctant about this one. It may result in a garbage being sent over the serial line after the resume (it's happended to me once in a couple of months, but still). > fix-jiffies-screw-up-on-SMP-x86_64.patch ... okay, this looks trivial > and needed. Not my area of code. Already in -mm. > swsusp-bitmaps-on-resume-fix.patch ... fixes speed problems, > IIRC. ACK. Yup. Already in -mm too. > i386-timer-debug.patch ... trivial and ok. ACK. It would be nice to > refactor it to some common code, but it is needed now. In -mm. > x86_64-timer-skew-on-resume.patch ... same as previous one. ACK. In -mm. > swap_type_of-fix.patch ... IIRC this one is already in (perhaps more > of these are?) This one has been merged by Linus. > swsusp-add-suspend_console.patch ... IIRC this is in, too? In -mm. > swsusp-add-suspend_console.patch ... in, IIRC? > > pm-make-suspend_console-configureable.patch ... this looks little > hacky, but I think it is in, too. In -mm. > pm-add-pm_trace-switch.patch ... I'm not sure if it is in or not, but > this one is needed. ACK. I have to check. If it's not in, I'll resend it. > swsusp-handle-highmem-better.patch ... I've reviewed this before. It > is a little complex, and I hope highmem just dies... it probably can > go in after lots of testing. I'd like to send this one for -mm after 2.6.19-rc1 is out, as potential 2.6.20 material. > swsusp-use-start-block.patch ... looks okay to me. ACK. Thanks. I'll send it for -mm after 2.6.18, as 2.6.19 material. > print-offset-for-swap-files.patch ... this actually changes userland > API. Not sure if that is acceptable; lots of discussion is needed. We > should probably drop /proc/swaps and just create something in sysfs. In sysfs we'd have to create a whole hierarchy of files to provide all of the information contained in /proc/swaps. And there would be a problem with file names. ;-) The procfs modification is not really needed, I added it for completness. The message from sys_swapon() should be enough. Or perhaps I'll just add a separate message in sys_swapon() containing the "real" block device name _and_ the offset for the newly activated swap. > swsusp-introduce-resume-offset.patch ... do we really need /sys file > setting up resume offset? Anyone needing that should really use > uswsusp. submit() move around probably should go into separate patch > (that can go in earlier). Okay, it is not as bad as I expected... Actually the resume_offset in sysfs is a mistake, because the offset should only be set along with the resume device and not separately. In fact each swap area is identified by a pair (blockdev, offset), where offset is trivially 0 for swap partitions, so for consistency of the data in sysfs we should set both at once (well, this may be handled with a hacky-whacky string parsing or something like that, but let's avoid such things ;-) ). We can pass the two values in the kernel command line or via a ioctl (by passing a pointer to a struct of two values). > Oh, new command line options need Documenting. Sure (the patch is experimental :-) ). > swsusp-resume-offset-in-user.patch ... aha, so you are _not_ planning > to use bmap() to handle swapfiles, instead you are doing it in kernel > :-(. OTOH code looks quite acceptable... actually bmap() would be > quite hard to with swapfiles, because you need to know what is empty > and what is not... so perhaps this is acceptable? Well, the code that sets up swap files _already_ uses bmap() so why should we duplicate it, either in the kernel or in the user space? The idea is that the code we need _is_ in the kernel and it does exactly what we'd like to do, so we only need to use it. Namely, from the technical point of view there are two differences between a swap partition and a swap file: (1) the swap file need not be continuous and (2) it doesn't start from the beginning of the block device that holds it. The swap-handling code in the kernel is designed so that (1) is handled automatically (that's why bmap() is used by it), and (2) is not a problem from the point of view of sys_swapon(), because the fs containing the swap file is mounted when it's called. Unfortunately for us (2) is a serious issue, because we cannot mount any filesystems during the resume and the resume code needs to know where to read the image header from (all of the information it needs are in the header). For this reason we need to identify the swap file in a fs-independent way and I thought it would be a good idea to use the pair (blockdev, offset) for this purpose, where offset is a place where there's the image header (by design it also is the location of the swap header, so we can obtain this information from the swap-related data structures). > > In short, the idea is that a swap file can be identified by the name of the > > block device which holds it and the offset from the beginning of the > > device. > > Are you sure swap files are always contiguous on the disk? I'm pretty > sure that is not the case. You're right, but it doesn't matter. :-) Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
