I didn't test with the proposed LZO update you mentioned. Sorry, which one do you mean? I did some tests with the latest LZO in the mainline. As a result, LZO is not faster in an unaligned access

Yes. However, it makes it more questionable to simply rip out compression methods without warning. Not that warnings help, as we have learned. -hpa

The fact that you are aware of it means we're not going to break them. But my point is that we must not be held back just in case someone out there might have painted himself in a corner without

I think they can be fairly flexible. Obviously gzip is always supported. I don't know the details. Well, it is too nasty for public confession, but it's called "paravirtualization". -hpa

Are you kidding? And what format do they expect? If people are doing weird things with formats we're about to remove then it's their fault if they didn't make upstream developers aware of it. And

Some utterly weird things like the Xen domain builder do that, because they have to. That is why we explicitly document that the payload is ELF and how to access it in the bzImage spec. -hpa

That would be hard to justify given that the kernel provides its own decompressor code, making the compression format transparent to bootloaders, etc. And no one should be poking into the

This reminded me to check the status of the lzo update and it seems it got lost? http://lkml.org/lkml/2012/10/3/144 (Cc: added, I hope Markus still cares and someone could eventually take his patch

The only concern I have with that is if someone paints themselves into a corner and absolutely wants, say, LZO. Otherwise, per your list it pretty much sounds like we should have lz4, gzip, and

Ok. We already have: - lzma: 33% smaller than gzip, decompression speed between gzip and bzip2 - xz: 30% smaller than gzip, decompression speed similar to lzma - bzip2: 10% smaller than gzip,

Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux: the problem gets more complicated as the "fastest" decompressor usually creates larger images which need more time to load

Well... when I saw this my immediate reaction was "oh no, yet another decompressor for the kernel". We have five of these things already. Do we really need a sixth? My feeling is that we should

In the embedded space, quick boot is a really important feature to have. Many people resort to awful hacks in order to improve boot time, and so I would welcome this option. I have seen arm systems

Uhm... you're saying we have to be at one extreme or the other? We probably could drop the legacy lzma format, but someone might rely on it. Nicolas Pitre <nico@...> wrote: -- Sent from my

I'm guessing this is referring to commit 5010192d5a. Well, we used to have only one compressed format. Now we have nearly half a dozen, with the same worthiness issue between themselves. Either

Yes, exactly. If the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then it is expected more boot-time improvement by LZ4-decompressor. Currently there are two architectures which support it

Kyungsik Lee <kyungsik.lee@...> wrote: What's this "with enabled unaligned memory access" thing? You mean "if the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so, that's only x86,

Hi everyone, The schedule for Embedded Linux Conference is now available at: http://events.linuxfoundation.org/events/embedded-linux-conference/schedule ELC is February 20-22 in San Francisco.

Greetings, Here are the videos of the latest edition of the Embedded Linux Conference Europe (ELC-E): http://free-electrons.com/blog/elce-2012-videos/ Make sure you don't miss the upcoming ELC next

From: Constantine Shulyupin <const@...> misc_loop_drv - simple sample driver with validation script. It implements loopback device with blocking and nonblocking read and write file