LZMA compression algorithm in Kernel - any chance to allow it?

LZMA compression algorithm in Kernel - any chance to allow it?

[Tomas M]

Hello.
I can see the 2.6.25 kernel includes LZO compression algorithm in:

[*] Cryptographic API
 < > LZO compression algorithm

As far as I could see, there was a strong pressure against putting compression algorithms in kernel. Does this LZO example mean that kernel people are now more open to include other algorithms as well? I'd like to include LZMA algo, which has far better compression ratio then anything else widely used today, and is already used in many small or embeded systems (as external patches to kernel or userspace utilities)

If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)


Thank you

Tomas M

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Jan Engelhardt]

On Thursday 2008-06-26 09:56, Tomas M wrote:

>If I (or anybody else) submit LZMA code for inclusion in kernel,
>would you ACCEPT IT ?? (assuming the code looks nice to you)

The bad thing is, they won't tell you before you submitted it.
The good thing is, that it may get accepted nevertheless if sent
often enough.

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Tomas M]

> The bad thing is, they won't tell you before you submitted it.

By 'they' you mean who?
Who decides what is accepted anyway?

    *  H. Peter Anvin, President ?
    * Jeff Uphoff, Treasurer ?
    * Chris Wright, Secretary ?
    * Kees Cook, Board Member ?
    * Linus Torvalds, Board Member ?

[names quoted from http://kernel.org/nonprofit.html:]


> The good thing is, that it may get accepted nevertheless if sent
> often enough.

Well that point is very interesting and useful indeed :)


Tomas M
slax.org

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Stefan Richter]

Tomas M wrote:
>> The bad thing is, they won't tell you before you submitted it.
> 
> By 'they' you mean who?
> Who decides what is accepted anyway?

Major contributors (reviewers, maintainers) do, and ultimately Linus.

You said LZMA is already used by out-of-tree code in the embedded
domain.  So I suppose a submission of an LZMA implementation should
rather be part of a submission of code which actually uses it.
-- 
Stefan Richter
-=====-==--- -==- ==-=-
http://arcgraph.de/sr/

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Pavel Machek]

On Thu 2008-06-26 09:56:23, Tomas M wrote:
> Hello.
> I can see the 2.6.25 kernel includes LZO compression algorithm in:
> 
> [*] Cryptographic API
>  < > LZO compression algorithm
> 
> As far as I could see, there was a strong pressure against putting compression algorithms in kernel. Does this LZO example mean that kernel people are now more open to include other algorithms as well? I'd like to include LZMA algo, which has far better compression ratio then anything else widely used today, and is already used in many small or embeded systems (as external patches to kernel or userspace utilities)
> 
> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)

You need some good reason why lzma should be in kernel... like 'cramfs
can use it'...?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Tomas M]

Well, I use LZMA particularly in squashfs, which is a replacement for cramfs at all.

Unfortunately even squashfs is not in kernel.



Tomas M


Pavel Machek wrote:
> On Thu 2008-06-26 09:56:23, Tomas M wrote:
>> Hello.
>> I can see the 2.6.25 kernel includes LZO compression algorithm in:
>>
>> [*] Cryptographic API
>>  < > LZO compression algorithm
>>
>> As far as I could see, there was a strong pressure against putting compression algorithms in kernel. Does this LZO example mean that kernel people are now more open to include other algorithms as well? I'd like to include LZMA algo, which has far better compression ratio then anything else widely used today, and is already used in many small or embeded systems (as external patches to kernel or userspace utilities)
>>
>> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)
> 
> You need some good reason why lzma should be in kernel... like 'cramfs
> can use it'...?
> 							Pavel

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Pavel Machek]

On Fri 2008-06-27 14:14:39, Tomas M wrote:
> Well, I use LZMA particularly in squashfs, which is a replacement for cramfs at all.
> 
> Unfortunately even squashfs is not in kernel.

That's good enough reason. Push squashfs first, or in same series as
lzma.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Jan Engelhardt]

On Thursday 2008-06-26 22:17, Pavel Machek wrote:
>> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)
>
>You need some good reason why lzma should be in kernel... like 'cramfs
>can use it'...?

squashfs if at all.

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Tomas M]

Jan Engelhardt wrote:
> On Thursday 2008-06-26 22:17, Pavel Machek wrote:
>>> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)
>> You need some good reason why lzma should be in kernel... like 'cramfs
>> can use it'...?
> 
> squashfs if at all.
> 

Well anything can use lzma or any other compressions, not only squashfs.
Squashfs is a great example, where you get 30% smaller filesystems compared to gzip.

Tomas M

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Josh Boyer]

On Fri, 2008-06-27 at 16:11 +0200, Tomas M wrote:
> Jan Engelhardt wrote:
> > On Thursday 2008-06-26 22:17, Pavel Machek wrote:
> >>> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)
> >> You need some good reason why lzma should be in kernel... like 'cramfs
> >> can use it'...?
> > 
> > squashfs if at all.
> > 
> 
> Well anything can use lzma or any other compressions, not only squashfs.
> Squashfs is a great example, where you get 30% smaller filesystems compared to gzip.

JFFS2 has an framework for having multiple compression algorithms.
Adding LZMA to that wouldn't be difficult either.

josh

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Jan Engelhardt]

On Friday 2008-06-27 16:11, Tomas M wrote:

>Jan Engelhardt wrote:
>> On Thursday 2008-06-26 22:17, Pavel Machek wrote:
>>>> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)
>>> You need some good reason why lzma should be in kernel... like 'cramfs
>>> can use it'...?
>> 
>> squashfs if at all.
>> 
>
>Well anything can use lzma or any other compressions, not only squashfs.
>Squashfs is a great example, where you get 30% smaller filesystems compared to gzip.

I rather meant "who would still use cramfs", given that squashfs
actually crams more files into the same space.

Re: LZMA compression algorithm in Kernel - any chance to allow it?

[Robert Hancock]

Tomas M wrote:
> Hello.
> I can see the 2.6.25 kernel includes LZO compression algorithm in:
> 
> [*] Cryptographic API
>  < > LZO compression algorithm
> 
> As far as I could see, there was a strong pressure against putting compression algorithms in kernel. Does this LZO example mean that kernel people are now more open to include other algorithms as well? I'd like to include LZMA algo, which has far better compression ratio then anything else widely used today, and is already used in many small or embeded systems (as external patches to kernel or userspace utilities)
> 
> If I (or anybody else) submit LZMA code for inclusion in kernel, would you ACCEPT IT ?? (assuming the code looks nice to you)

Not if there is nothing that uses it. If you have a place in the kernel 
that could make good use of such compression, which couldn't easily be 
handled outside the kernel, and you update it to use it, I would guess 
it would likely be accepted.