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
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.
> 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
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/
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.
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
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
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
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.
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
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
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.