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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
