[LUCID] pull request - replace compcache with ramzswap

[manoj.iyer at canonical.com]

apw,

Yes, this will require new userspace tools, and also change in the way the 
module is loaded. That is why I mentioned that I am not sure it works the 
same as compcache we already have.

Going by 'if it ain't broken don't fix it' we can put this off to the next 
release. I am totally fine with that.

Cheers
--- manjo

On Wed, 6 Jan 2010, Andy Whitcroft wrote:

> On Wed, Jan 06, 2010 at 09:53:06AM -0600, Manoj Iyer wrote:
>>
>> This pull request removes compcache from ubuntu delta and adds the latest
>> ramzsawp (aka compcache) to staging. I built a kernel (with
>> skipmodules=true), and it is available under
>> http://people.canonical.com/~manjo/lucid/ramzswap/
>> I have not tested if the latest ramzswap works the same as compcahe, but
>> from the mailing list the latest changes to ramzsawp (aka compcache) are
>> reported to work.
>
> The first concern here would be that the name of the driver seems to
> be changing from compcache to ramzswap.  However, I had a look at our
> existing ubuntu/compcache version and actually if you look at the Makefile
> it makes the module ramzswap also:
>
>  obj-$(CONFIG_BLK_DEV_COMPCACHE) := ramzswap.o xvmalloc.o
>
> Looking at the compcache support in the initramfs it seems it already
> has to cope with compcache and ramzswap as names.  However, this new
> version seems to have completely different use semantics.  We assume it
> can be directly built as below:
>
>    modprobe -q --ignore-install ramzswap disksize_kb="$kbytes"
>
> but the new version only takes one module parameter:
>
>    modprobe ramzswap num_devices=4
>
> and relies on a new userspace tool to generate the actual devices:
>
>    rzscontrol /dev/ramzswap2 --disksize_kb=XXX --init
>
> so we would need to get that userspace tool as well to make this work
> and update the initramfs support to trigger it.
>
>>   drivers/staging/Makefile                           |    1 +
>>   drivers/staging/ramzswap/Kconfig                   |   21 +
>
> Finally I think if we could include this we would want to rename it over
> to ubuntu for consitancy.
>
> Overall if we do move to this version we would need to pull in the
> userspace tools as a new package and we would also need to be able to
> detect which version of ramzswap we have to adjust to the appropriate
> semantics.
>
> Cirtainly we cannot just blindly apply this this close to Alpha, if at
> all during lucid.  I am inclined to suggest we stay with what we know
> for this cycle and put this on the radar for M.
>
> -apw
>