On Thu, Aug 13, 2015 at 12:51:13PM +0900, Sergey Senozhatsky wrote:
On (08/13/15 11:24), Joonsoo Kim wrote:
Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram if needed.
On Thu, Aug 13, 2015 at 04:19:41PM +0900, Joonsoo Kim wrote:
If that optimization is really needed for the case that doesn't need
tfm except fetching function pointer, we can implement sharable tfm
in crypto subsystem.
I'm happy to consider changes to the crypto compression interface
as long
On Thu, Aug 13, 2015 at 03:32:33PM +0800, Herbert Xu wrote:
On Thu, Aug 13, 2015 at 04:19:41PM +0900, Joonsoo Kim wrote:
If that optimization is really needed for the case that doesn't need
tfm except fetching function pointer, we can implement sharable tfm
in crypto subsystem.
I'm
Removed Herbert, David, Stephan not spam their mail boxes.
I'd rather investigate something like this.
WARNING!!! NOT TESTED AT ALL! like for real... only compile tested.
RFC
define ZLIB backend the same way as we already do. and introduce
compression frontend -flags field. backend that
Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram if needed. Without this work,
we cannot utilize various compression algorithms in the system.
Moreover, to add new compression
On (08/13/15 11:24), Joonsoo Kim wrote:
Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram if needed. Without this work,
we cannot utilize various compression algorithms in
