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.
>
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 l
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 nee
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 req
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 i
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 a
6 matches
Mail list logo
