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.
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
>> 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
> 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.
kernel-team mailing list