On Fri, Apr 27, 2007 at 06:08:01AM +1000, Nigel Cunningham wrote: > We tried that. It would need some work. IIRC remounting filesystems > read-only makes files become marked read-only. Perfectly sensible, > except that if you then remount the filesystem rw at resume time, all > those files are still marked ro and userspace crashes and burns. Not > unfixable, I'll agree, but there is more work to do there.
There are other solutions, though. One is that we could export a system call interface which freezes a filesystem and prevents any further I/O. We mostly have something like that right now (via the the write_super_lockfs function in the superblock operations structure), but we haven't exported it to userspace. And right now not all filesystems support it, but in theory that could be fixed (or you only suppor suspend/resume if all filesystems support lockfs). We would also need a similar interface to freeze any block device I/O, in case you have a database running and doing direct I/O to a block device. (Or again, we could simply not support that case; how many people will be running running a database accessing a block deivce on their laptop?) So in order to do this right, we would have to double the number of new interfaces needed from the two proposed by Linus --- which is why I think the userspace suspend solution is fundamentally NOT the right one. Rather the right one is the one which Linux ultimately used for PCMCIA, which is to do it all in the kernel. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/