Re: [RFC][PATCH] PM / Hibernate: Modify signature used to mark swap

[Nigel Cunningham]

Hi.

On 30/09/10 08:02, Rafael J. Wysocki wrote:
> On Wednesday, September 29, 2010, Nigel Cunningham wrote:
> > Hi.
> >
> > On 30/09/10 07:13, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki<rjw@xxxxxxx>
> > > Subject: PM / Hibernate: Modify signature used to mark swap
> > >
> > > Since we are adding compression to the kernel's hibernate code,
> > > change signature used by it to mark swap spaces, so that earlier
> > > kernels don't attempt to restore compressed images they cannot
> > > handle.
> > >
> > > Signed-off-by: Rafael J. Wysocki<rjw@xxxxxxx>
> > > ---
> > >    kernel/power/swap.c |    6 +++---
> > >    1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > Index: linux-2.6/kernel/power/swap.c
> > > ===================================================================
> > > --- linux-2.6.orig/kernel/power/swap.c
> > > +++ linux-2.6/kernel/power/swap.c
> > > @@ -29,7 +29,7 @@
> > >
> > >    #include "power.h"
> > >
> > > -#define SWSUSP_SIG	"S1SUSPEND"
> > > +#define HIBERNATE_SIG	"LINHIB0001"
> > >
> > >    /*
> > >     *	The swap map is a data structure used for keeping track of each page
> > > @@ -195,7 +195,7 @@ static int mark_swapfiles(struct swap_ma
> > >    	if (!memcmp("SWAP-SPACE",swsusp_header->sig, 10) ||
> > >    	    !memcmp("SWAPSPACE2",swsusp_header->sig, 10)) {
> > >    		memcpy(swsusp_header->orig_sig,swsusp_header->sig, 10);
> >
> > if no compression
> >
> > > -		memcpy(swsusp_header->sig,SWSUSP_SIG, 10);
> >
> > else
> >
> > > +		memcpy(swsusp_header->sig, HIBERNATE_SIG, 10);
> >
> > ??
>
> I thought about that, but we'll need to drop the old signature when the image
> format changes (I think it will after your patch series) anyway.  And the
> benefit is not really worth it IMO (it only affects people using the in-kernel
> hibernation on x86-64).

Okay. I'm just a little weary because if everything I want to get in 
gets in, we're going to then be changing this signature multiple times. 
I want to eventually reach a situation where we have a 'proper' header 
section to the image that stores (among other things) whether 
compression is enabled and which cryptoapi algorithm is used, allowing a 
person to en/disable compression at runtime without recompiling or 
rebooting. I suppose if I seek to put that stuff in earlier rather than 
later, that will simplify things.

Oh, while I'm writing to you: let's not worry about getting my patches 
in for 2.6.37. I won't be working on them much today, and want to put 
the time into making sure they're right before they get merged. As you 
said - let's seek to get things right first time.

Regards,

Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/