Both zram and zcache use xvmalloc allocator. If xvmalloc
is compiled separately for both of them, we will get linker
error if they are both selected as "built-in". We can also
get linker error regarding missing xvmalloc symbols if zram
is not built.
So, we now compile xvmalloc separately and export its symbols
which are then used by both of zram and zcache.
Signed-off-by: Nitin Gupta <[email protected]>
---
drivers/staging/Makefile | 1 +
drivers/staging/zcache/Makefile | 4 +++-
drivers/staging/zram/Kconfig | 5 +++++
drivers/staging/zram/Makefile | 3 ++-
drivers/staging/zram/xvmalloc.c | 8 ++++++++
5 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 9edbfec..f7ab035 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_DX_SEP) += sep/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_CS5535_GPIO) += cs5535_gpio/
obj-$(CONFIG_ZRAM) += zram/
+obj-$(CONFIG_XVMALLOC) += zram/
obj-$(CONFIG_ZCACHE) += zcache/
obj-$(CONFIG_WLAGS49_H2) += wlags49_h2/
obj-$(CONFIG_WLAGS49_H25) += wlags49_h25/
diff --git a/drivers/staging/zcache/Makefile b/drivers/staging/zcache/Makefile
index 7f64de4..f5ec64f 100644
--- a/drivers/staging/zcache/Makefile
+++ b/drivers/staging/zcache/Makefile
@@ -1 +1,3 @@
-obj-$(CONFIG_ZCACHE) += zcache.o tmem.o
+zcache-y := tmem.o
+
+obj-$(CONFIG_ZCACHE) += zcache.o
diff --git a/drivers/staging/zram/Kconfig b/drivers/staging/zram/Kconfig
index da079f8..1516ea4 100644
--- a/drivers/staging/zram/Kconfig
+++ b/drivers/staging/zram/Kconfig
@@ -1,6 +1,11 @@
+config XVMALLOC
+ bool
+ default n
+
config ZRAM
tristate "Compressed RAM block device support"
depends on BLOCK
+ select XVMALLOC
select LZO_COMPRESS
select LZO_DECOMPRESS
default n
diff --git a/drivers/staging/zram/Makefile b/drivers/staging/zram/Makefile
index b1709c5..2a6d321 100644
--- a/drivers/staging/zram/Makefile
+++ b/drivers/staging/zram/Makefile
@@ -1,3 +1,4 @@
-zram-y := zram_drv.o zram_sysfs.o xvmalloc.o
+zram-y := zram_drv.o zram_sysfs.o
obj-$(CONFIG_ZRAM) += zram.o
+obj-$(CONFIG_XVMALLOC) += xvmalloc.o
\ No newline at end of file
diff --git a/drivers/staging/zram/xvmalloc.c b/drivers/staging/zram/xvmalloc.c
index b644067..aa6fcd8 100644
--- a/drivers/staging/zram/xvmalloc.c
+++ b/drivers/staging/zram/xvmalloc.c
@@ -10,6 +10,8 @@
* Released under the terms of GNU General Public License Version 2.0
*/
+#include <linux/module.h>
+#include <linux/kernel.h>
#include <linux/bitops.h>
#include <linux/errno.h>
#include <linux/highmem.h>
@@ -320,11 +322,13 @@ struct xv_pool *xv_create_pool(void)
return pool;
}
+EXPORT_SYMBOL_GPL(xv_create_pool);
void xv_destroy_pool(struct xv_pool *pool)
{
kfree(pool);
}
+EXPORT_SYMBOL_GPL(xv_destroy_pool);
/**
* xv_malloc - Allocate block of given size from pool.
@@ -413,6 +417,7 @@ int xv_malloc(struct xv_pool *pool, u32 size, struct page **page,
return 0;
}
+EXPORT_SYMBOL_GPL(xv_malloc);
/*
* Free block identified with <page, offset>
@@ -489,6 +494,7 @@ void xv_free(struct xv_pool *pool, struct page *page, u32 offset)
put_ptr_atomic(page_start, KM_USER0);
spin_unlock(&pool->lock);
}
+EXPORT_SYMBOL_GPL(xv_free);
u32 xv_get_object_size(void *obj)
{
@@ -497,6 +503,7 @@ u32 xv_get_object_size(void *obj)
blk = (struct block_header *)((char *)(obj) - XV_ALIGN);
return blk->size;
}
+EXPORT_SYMBOL_GPL(xv_get_object_size);
/*
* Returns total memory used by allocator (userdata + metadata)
@@ -505,3 +512,4 @@ u64 xv_get_total_size_bytes(struct xv_pool *pool)
{
return pool->total_pages << PAGE_SHIFT;
}
+EXPORT_SYMBOL_GPL(xv_get_total_size_bytes);
--
1.7.3.5
On 02/10/11 13:00, Nitin Gupta wrote:
> Both zram and zcache use xvmalloc allocator. If xvmalloc
> is compiled separately for both of them, we will get linker
> error if they are both selected as "built-in". We can also
> get linker error regarding missing xvmalloc symbols if zram
> is not built.
>
> So, we now compile xvmalloc separately and export its symbols
> which are then used by both of zram and zcache.
>
> Signed-off-by: Nitin Gupta <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
but what does this patch apply to? It does not apply cleanly to
linux-next of 20110210.
> ---
> drivers/staging/Makefile | 1 +
> drivers/staging/zcache/Makefile | 4 +++-
> drivers/staging/zram/Kconfig | 5 +++++
> drivers/staging/zram/Makefile | 3 ++-
> drivers/staging/zram/xvmalloc.c | 8 ++++++++
> 5 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 9edbfec..f7ab035 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_DX_SEP) += sep/
> obj-$(CONFIG_IIO) += iio/
> obj-$(CONFIG_CS5535_GPIO) += cs5535_gpio/
> obj-$(CONFIG_ZRAM) += zram/
> +obj-$(CONFIG_XVMALLOC) += zram/
> obj-$(CONFIG_ZCACHE) += zcache/
> obj-$(CONFIG_WLAGS49_H2) += wlags49_h2/
> obj-$(CONFIG_WLAGS49_H25) += wlags49_h25/
> diff --git a/drivers/staging/zcache/Makefile b/drivers/staging/zcache/Makefile
> index 7f64de4..f5ec64f 100644
> --- a/drivers/staging/zcache/Makefile
> +++ b/drivers/staging/zcache/Makefile
> @@ -1 +1,3 @@
> -obj-$(CONFIG_ZCACHE) += zcache.o tmem.o
> +zcache-y := tmem.o
> +
> +obj-$(CONFIG_ZCACHE) += zcache.o
> diff --git a/drivers/staging/zram/Kconfig b/drivers/staging/zram/Kconfig
> index da079f8..1516ea4 100644
> --- a/drivers/staging/zram/Kconfig
> +++ b/drivers/staging/zram/Kconfig
> @@ -1,6 +1,11 @@
> +config XVMALLOC
> + bool
> + default n
> +
> config ZRAM
> tristate "Compressed RAM block device support"
> depends on BLOCK
> + select XVMALLOC
> select LZO_COMPRESS
> select LZO_DECOMPRESS
> default n
> diff --git a/drivers/staging/zram/Makefile b/drivers/staging/zram/Makefile
> index b1709c5..2a6d321 100644
> --- a/drivers/staging/zram/Makefile
> +++ b/drivers/staging/zram/Makefile
> @@ -1,3 +1,4 @@
> -zram-y := zram_drv.o zram_sysfs.o xvmalloc.o
> +zram-y := zram_drv.o zram_sysfs.o
>
> obj-$(CONFIG_ZRAM) += zram.o
> +obj-$(CONFIG_XVMALLOC) += xvmalloc.o
> \ No newline at end of file
> diff --git a/drivers/staging/zram/xvmalloc.c b/drivers/staging/zram/xvmalloc.c
> index b644067..aa6fcd8 100644
> --- a/drivers/staging/zram/xvmalloc.c
> +++ b/drivers/staging/zram/xvmalloc.c
> @@ -10,6 +10,8 @@
> * Released under the terms of GNU General Public License Version 2.0
> */
>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> #include <linux/bitops.h>
> #include <linux/errno.h>
> #include <linux/highmem.h>
> @@ -320,11 +322,13 @@ struct xv_pool *xv_create_pool(void)
>
> return pool;
> }
> +EXPORT_SYMBOL_GPL(xv_create_pool);
>
> void xv_destroy_pool(struct xv_pool *pool)
> {
> kfree(pool);
> }
> +EXPORT_SYMBOL_GPL(xv_destroy_pool);
>
> /**
> * xv_malloc - Allocate block of given size from pool.
> @@ -413,6 +417,7 @@ int xv_malloc(struct xv_pool *pool, u32 size, struct page **page,
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(xv_malloc);
>
> /*
> * Free block identified with <page, offset>
> @@ -489,6 +494,7 @@ void xv_free(struct xv_pool *pool, struct page *page, u32 offset)
> put_ptr_atomic(page_start, KM_USER0);
> spin_unlock(&pool->lock);
> }
> +EXPORT_SYMBOL_GPL(xv_free);
>
> u32 xv_get_object_size(void *obj)
> {
> @@ -497,6 +503,7 @@ u32 xv_get_object_size(void *obj)
> blk = (struct block_header *)((char *)(obj) - XV_ALIGN);
> return blk->size;
> }
> +EXPORT_SYMBOL_GPL(xv_get_object_size);
>
> /*
> * Returns total memory used by allocator (userdata + metadata)
> @@ -505,3 +512,4 @@ u64 xv_get_total_size_bytes(struct xv_pool *pool)
> {
> return pool->total_pages << PAGE_SHIFT;
> }
> +EXPORT_SYMBOL_GPL(xv_get_total_size_bytes);
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 02/11/2011 02:38 AM, Randy Dunlap wrote:
> On 02/10/11 13:00, Nitin Gupta wrote:
>> Both zram and zcache use xvmalloc allocator. If xvmalloc
>> is compiled separately for both of them, we will get linker
>> error if they are both selected as "built-in". We can also
>> get linker error regarding missing xvmalloc symbols if zram
>> is not built.
>>
>> So, we now compile xvmalloc separately and export its symbols
>> which are then used by both of zram and zcache.
>>
>> Signed-off-by: Nitin Gupta<[email protected]>
>
> Acked-by: Randy Dunlap<[email protected]>
>
>
> but what does this patch apply to? It does not apply cleanly to
> linux-next of 20110210.
>
This applies to staging-2.6. I thought linux-next won't be that
different so as to produce conflicts. Can you please send reject files,
or let me fetch linux-next tree and will soon post patch against the same.
Thanks,
Nitin
On 02/10/11 13:12, Nitin Gupta wrote:
> On 02/11/2011 02:38 AM, Randy Dunlap wrote:
>> On 02/10/11 13:00, Nitin Gupta wrote:
>>> Both zram and zcache use xvmalloc allocator. If xvmalloc
>>> is compiled separately for both of them, we will get linker
>>> error if they are both selected as "built-in". We can also
>>> get linker error regarding missing xvmalloc symbols if zram
>>> is not built.
>>>
>>> So, we now compile xvmalloc separately and export its symbols
>>> which are then used by both of zram and zcache.
>>>
>>> Signed-off-by: Nitin Gupta<[email protected]>
>>
>> Acked-by: Randy Dunlap<[email protected]>
>>
>>
>> but what does this patch apply to? It does not apply cleanly to
>> linux-next of 20110210.
>>
>
> This applies to staging-2.6. I thought linux-next won't be that
> different so as to produce conflicts. Can you please send reject files,
> or let me fetch linux-next tree and will soon post patch against the same.
I'll let you fetch linux-next. I merged it by hand and test-built it
successfully.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 02/11/2011 02:47 AM, Randy Dunlap wrote:
> On 02/10/11 13:12, Nitin Gupta wrote:
>> On 02/11/2011 02:38 AM, Randy Dunlap wrote:
>>> On 02/10/11 13:00, Nitin Gupta wrote:
>>>> Both zram and zcache use xvmalloc allocator. If xvmalloc
>>>> is compiled separately for both of them, we will get linker
>>>> error if they are both selected as "built-in". We can also
>>>> get linker error regarding missing xvmalloc symbols if zram
>>>> is not built.
>>>>
>>>> So, we now compile xvmalloc separately and export its symbols
>>>> which are then used by both of zram and zcache.
>>>>
>>>> Signed-off-by: Nitin Gupta<[email protected]>
>>>
>>> Acked-by: Randy Dunlap<[email protected]>
>>>
>>>
>>> but what does this patch apply to? It does not apply cleanly to
>>> linux-next of 20110210.
>>>
>>
>> This applies to staging-2.6. I thought linux-next won't be that
>> different so as to produce conflicts. Can you please send reject files,
>> or let me fetch linux-next tree and will soon post patch against the same.
>
> I'll let you fetch linux-next. I merged it by hand and test-built it
> successfully.
>
So, can you post the patch against linux-next then? :)
Thanks,
Nitin
On 02/10/11 13:20, Nitin Gupta wrote:
> On 02/11/2011 02:47 AM, Randy Dunlap wrote:
>> On 02/10/11 13:12, Nitin Gupta wrote:
>>> On 02/11/2011 02:38 AM, Randy Dunlap wrote:
>>>> On 02/10/11 13:00, Nitin Gupta wrote:
>>>>> Both zram and zcache use xvmalloc allocator. If xvmalloc
>>>>> is compiled separately for both of them, we will get linker
>>>>> error if they are both selected as "built-in". We can also
>>>>> get linker error regarding missing xvmalloc symbols if zram
>>>>> is not built.
>>>>>
>>>>> So, we now compile xvmalloc separately and export its symbols
>>>>> which are then used by both of zram and zcache.
>>>>>
>>>>> Signed-off-by: Nitin Gupta<[email protected]>
>>>>
>>>> Acked-by: Randy Dunlap<[email protected]>
>>>>
>>>>
>>>> but what does this patch apply to? It does not apply cleanly to
>>>> linux-next of 20110210.
>>>>
>>>
>>> This applies to staging-2.6. I thought linux-next won't be that
>>> different so as to produce conflicts. Can you please send reject files,
>>> or let me fetch linux-next tree and will soon post patch against the
>>> same.
>>
>> I'll let you fetch linux-next. I merged it by hand and test-built it
>> successfully.
>>
>
> So, can you post the patch against linux-next then? :)
it's attached since I don't trust thunderbird.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Thu, Feb 10, 2011 at 04:00:46PM -0500, Nitin Gupta wrote:
> Both zram and zcache use xvmalloc allocator. If xvmalloc
> is compiled separately for both of them, we will get linker
> error if they are both selected as "built-in". We can also
> get linker error regarding missing xvmalloc symbols if zram
> is not built.
>
> So, we now compile xvmalloc separately and export its symbols
> which are then used by both of zram and zcache.
>
> Signed-off-by: Nitin Gupta <[email protected]>
This doesn't apply to my tree, care to respin it and resend?
thanks,
greg k-h
On 02/19/2011 02:55 AM, Greg KH wrote:
> On Thu, Feb 10, 2011 at 04:00:46PM -0500, Nitin Gupta wrote:
>> Both zram and zcache use xvmalloc allocator. If xvmalloc
>> is compiled separately for both of them, we will get linker
>> error if they are both selected as "built-in". We can also
>> get linker error regarding missing xvmalloc symbols if zram
>> is not built.
>>
>> So, we now compile xvmalloc separately and export its symbols
>> which are then used by both of zram and zcache.
>>
>> Signed-off-by: Nitin Gupta<[email protected]>
>
> This doesn't apply to my tree, care to respin it and resend?
>
The new patch:
https://lkml.org/lkml/2011/2/18/340
applies to staging-next branch of the staging-2.6 tree.
Thanks,
Nitin