On Mon, Jul 16, 2007 at 11:42:08PM -0700, [EMAIL PROTECTED] wrote: > On Tue, 17 Jul 2007, Joseph Fannin wrote:
> >root is free to "dd if=/dev/random of=/dev/mem". Root owned > >daemons which do bad things are bugs. > > in this case it would be more like > > dd if=/block0 of=/dev/sda1 count=1 bs=4096 skip=5000 > dd if=/block1 of=/dev/sda1 count=1 bs=4096 skip=5050 > dd if=/block2 of=/dev/sda1 count=1 bs=4096 skip=5400 > etc > > to write the blocks to the raw parition in the right place What I meant by that was that root is allowed to shoot himself in the foot. Nothing stops root from opening a swap/hibernate file, which would put it in cache, and cause it to be inconsistant if a hibernation image was written to it behind the kernel's back. That would be a very stupid thing to do, however. There's no reason to open that file, unless you know *exactly* what you are doing, in which case the onus is on you to get it right. But you have a point. The swap file could be very fragmented. It might often be so, even. Still, is this better than exporting the kernel's swap internals (which has never been a public interface before)? Does it make the interface that writing hibernation images to swap imposes any better? Even if hibernation files are no less complicated to support than hibernating to swap files (which isn't a forgone conclusion) , there are plenty of reasons writing hibernation images to swap doesn't make sense. > >Again, supporting swap files (*which is not optional*) requires the > >very same support. > > in the kexec model why would the second kernel care about swap files at > all? (unles it chooses to write to them, in which case it is exactly the > same support, but unless it writes to them it doesn't need to care) My point is that no extra work is required to write hibernation images to dedicated files than to write hibernation images to swap files. If swap files are to be supported, then, there's no technical reason not to support dedicated hibernation files. Dedicated hibernation files are better, and there's no reason not to implement them. -- Joseph Fannin [EMAIL PROTECTED] - 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/
