Uncompressed kernel doesn't build on x86_64

[Pavel Roskin]

Hi Christian,

Your recent patch enables uncompressed kernels, but selecting that
option (CONFIG_KERNEL_UNCOMPRESSED) fails on x86_86:

commit 69f0554ec261fd686ac7fa1c598cc9eb27b83a80
Author: Christian Ruppert <christia...@abilis.com>
Date: Tue Nov 12 15:11:43 2013 -0800

init/Kconfig: add option to disable kernel compression

That's how it fails:

LD init/built-in.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
VOFFSET arch/x86/boot/voffset.h
make[4]: *** No rule to make target
`arch/x86/boot/compressed/vmlinux.bin.', needed by
`arch/x86/boot/compressed/piggy.S'. Stop. make[3]: ***
[arch/x86/boot/compressed/vmlinux] Error 2 make[2]: *** [bzImage]
Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2

arch/x86/boot/compressed/Makefile has no provision for uncompressed
files. There is no definition for suffix-$(CONFIG_KERNEL_UNCOMPRESSED)
so $(suffix-y) evaluates to an empty string and there is no rule to
make vmlinuz.bin.$(suffix-y)

I think the patch should be either reverted or fixed as soon as
possible.

Any suggestions for uncompressed suffix? I'd go with "copy". Then the
"compression" could be a symlink. Alternatively, the "." could be
included in other suffixes, the uncompressed suffix would be empty and
the compression would be an empty statement.

--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[H. Peter Anvin]

On 11/13/2013 08:34 AM, Pavel Roskin wrote:
>
> Any suggestions for uncompressed suffix? I'd go with "copy". Then the
> "compression" could be a symlink. Alternatively, the "." could be
> included in other suffixes, the uncompressed suffix would be empty and
> the compression would be an empty statement.
>

The latter would be my preference.

-hpa

[Christian Ruppert]

On Wed, Nov 13, 2013 at 11:34:18AM -0500, Pavel Roskin wrote:
> Hi Christian,
>
> Your recent patch enables uncompressed kernels, but selecting that
> option (CONFIG_KERNEL_UNCOMPRESSED) fails on x86_86:

> [...]

> arch/x86/boot/compressed/Makefile has no provision for uncompressed
> files. There is no definition for suffix-$(CONFIG_KERNEL_UNCOMPRESSED)
> so $(suffix-y) evaluates to an empty string and there is no rule to
> make vmlinuz.bin.$(suffix-y)
>
> I think the patch should be either reverted or fixed as soon as
> possible.

This is an interesting observation, thanks. Although this patch is
rather intended for embedded architectures than x86, it highlights
potential issues with self-decompressing images of all sorts. I have no
way of testing all architectures and so I'm sending two patches in the
follow-up:
1. A conservative version of the original patch which requires
architectures to explicitly enable uncompresed kernel images if they
support compression as well and falls back to previous behaviour if
nothing is specified. I have copied Vineet Gupta (maintainer of the
ARC platform) since I enabled GZIP and uncompressed kernels for ARC
by default.
2. A patch to enable uncompressed x86 kernels. As stated above, I don't
think this makes a lot of sense in itself but it might serve as an
example for people working on other platforms with self-extracting
kernels and the nozip not-decompression algorithm might be useful on
those platforms as well. I only had a single x86-64 machine available
to test this, however, so some more testing might be required.

> Any suggestions for uncompressed suffix? I'd go with "copy". Then the
> "compression" could be a symlink. Alternatively, the "." could be
> included in other suffixes, the uncompressed suffix would be empty and
> the compression would be an empty statement.

I followed H. Peter's suggestion and chose option 2 in patch 2.

Greetings,
Christian

[Austin S Hemmelgarn]

On 2013-11-14 03:32, Christian Ruppert wrote:
> 2. A patch to enable uncompressed x86 kernels. As stated above, I don't
> think this makes a lot of sense in itself but it might serve as an
> example for people working on other platforms with self-extracting
> kernels and the nozip not-decompression algorithm might be useful on
> those platforms as well. I only had a single x86-64 machine available
> to test this, however, so some more testing might be required.

I disagree with the argument that an uncompressed x86 kernel doesn't
make sense, If you have a very fast boot device, then it is fully
conceivable that an uncompressed kernel could boot faster than a
compressed one. I have seen a very large number of systems where the
LZO compression boots at least twice as fast as gzip or bz2 (because the
disks are fast enough that a few megabytes of size difference make much
less of an impact than a slow decompressor).

[Pavel Roskin]

On Thu, 14 Nov 2013 09:13:44 -0500
Austin S Hemmelgarn <ahfer...@gmail.com> wrote:

> On 2013-11-14 03:32, Christian Ruppert wrote:
> > 2. A patch to enable uncompressed x86 kernels. As stated above, I
> > don't think this makes a lot of sense in itself but it might serve
> > as an example for people working on other platforms with
> > self-extracting kernels and the nozip not-decompression algorithm
> > might be useful on those platforms as well. I only had a single
> > x86-64 machine available to test this, however, so some more
> > testing might be required.
>
> I disagree with the argument that an uncompressed x86 kernel doesn't
> make sense, If you have a very fast boot device, then it is fully
> conceivable that an uncompressed kernel could boot faster than a
> compressed one. I have seen a very large number of systems where the
> LZO compression boots at least twice as fast as gzip or bz2 (because
> the disks are fast enough that a few megabytes of size difference
> make much less of an impact than a slow decompressor).

I concur, the uncompressed kernel certainly makes sense in some cases.

If the kernel runs in an emulator, decompression could be slow.

If the kernel runs in a virtual machine, the kernel would need to be
decompressed separately for every virtual machine. Reading from the
disk would be done only once if several virtual machines are started in
a short period of time.

--
Regards,
Pavel Roskin