video (VGA) object-files unconditionally built/included?

video (VGA) object-files unconditionally built/included?

[Dag Bakke]

Hi.

I am putting together a tiny kernel for an embedded x86 target. Space is
tight, so I try to shave every kB I can get rid of.
I don't have anything resembling VGA or graphics, and my .config
reflects that. (Serial console.)

Yet, when building the kernel I see:

  LZMA    arch/x86/boot/compressed/vmlinux.bin.lzma
  CC      arch/x86/boot/video.o
  CC      arch/x86/boot/video-mode.o
  CC      arch/x86/boot/version.o
  CC      arch/x86/boot/video-vga.o
  CC      arch/x86/boot/video-vesa.o
  CC      arch/x86/boot/video-bios.o

# strings arch/x86/boot/bzImage | egrep -i 'vesa|vga|bios|mode'
+VESA
0123456789ABCDEFPress <ENTER> to see video modes available, <SPACE> to
continue, or wait 30 sec
Mode: Resolution:  Type:
Enter a video mode or "scan" to scan for additional modes:
Undefined video mode number: %x
VESA
BIOS


The video* objects sums up to 87kB. Can I get rid of that somehow? I am
using current git.

This is my .config:
http://tapas.homeip.net/~dagb/tiny.config

Cc: is appreciated.



Thanks,

Dag B

Re: video (VGA) object-files unconditionally built/included?

[Andrew Morton]

On Fri, 10 Apr 2009 13:30:22 +0200 Dag Bakke <dag@bakke.com> wrote:

> Hi.
> 
> I am putting together a tiny kernel for an embedded x86 target. Space is
> tight, so I try to shave every kB I can get rid of.
> I don't have anything resembling VGA or graphics, and my .config
> reflects that. (Serial console.)
> 
> Yet, when building the kernel I see:
> 
>   LZMA    arch/x86/boot/compressed/vmlinux.bin.lzma
>   CC      arch/x86/boot/video.o
>   CC      arch/x86/boot/video-mode.o
>   CC      arch/x86/boot/version.o
>   CC      arch/x86/boot/video-vga.o
>   CC      arch/x86/boot/video-vesa.o
>   CC      arch/x86/boot/video-bios.o
> 
> # strings arch/x86/boot/bzImage | egrep -i 'vesa|vga|bios|mode'
> +VESA
> 0123456789ABCDEFPress <ENTER> to see video modes available, <SPACE> to
> continue, or wait 30 sec
> Mode: Resolution:  Type:
> Enter a video mode or "scan" to scan for additional modes:
> Undefined video mode number: %x
> VESA
> BIOS
> 
> 
> The video* objects sums up to 87kB. Can I get rid of that somehow? I am
> using current git.
> 
> This is my .config:
> http://tapas.homeip.net/~dagb/tiny.config
> 

I don't think those video things end up consuming memory after the
kernel has booted?

Re: video (VGA) object-files unconditionally built/included?

[H. Peter Anvin]

Andrew Morton wrote:
>>
>> The video* objects sums up to 87kB. Can I get rid of that somehow? I am
>> using current git.
>>
>> This is my .config:
>> http://tapas.homeip.net/~dagb/tiny.config
> 
> I don't think those video things end up consuming memory after the
> kernel has booted?
> 

They aren't.  Plus, they don't add up to 87K -- more like 13K.

	-hpa

Re: video (VGA) object-files unconditionally built/included?

[Dag Bakke]

H. Peter Anvin wrote, On 04/11/2009 06:04 AM:
> Andrew Morton wrote:
>>>
>>> The video* objects sums up to 87kB. Can I get rid of that somehow? I am
>>> using current git.
>>>
>>> This is my .config:
>>> http://tapas.homeip.net/~dagb/tiny.config
>>
>> I don't think those video things end up consuming memory after the
>> kernel has booted?
>>
> 
> They aren't.  Plus, they don't add up to 87K -- more like 13K.
> 

First, I was more concerned about the size of the kernel image in the
flash memory, not runtime size. Is there an intrinsic reason these bits
must be part of the kernel image?


Second, my reasoning for the claim of 87k:

The build process goes like this:
[.....]
  LZMA    arch/x86/boot/compressed/vmlinux.bin.lzma
[....]
  CC      arch/x86/boot/video.o
  CC      arch/x86/boot/video-mode.o
  CC      arch/x86/boot/version.o
  CC      arch/x86/boot/video-vga.o
  CC      arch/x86/boot/video-vesa.o
  CC      arch/x86/boot/video-bios.o
[... no further compression? ...]
  BUILD   arch/x86/boot/bzImage

So the videobits appear to be built and added on to the kernel image
after the main chunk gets compressed. And the size of the video*.o
objects sums up to 87k.


If my reasoning is too stupid for words, would you mind providing a
graphical illustration of my stupidity?  :-)


Dag B

Re: video (VGA) object-files unconditionally built/included?

[H. Peter Anvin]

Dag Bakke wrote:
> 
> So the videobits appear to be built and added on to the kernel image
> after the main chunk gets compressed. And the size of the video*.o
> objects sums up to 87k.
> 
> If my reasoning is too stupid for words, would you mind providing a
> graphical illustration of my stupidity?  :-)
> 

It's not our job to do yours for you.

*.o files contain a LOT of metadata.  The "size" command tells you the
real size.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: video (VGA) object-files unconditionally built/included?

[Dag Bakke]

H. Peter Anvin wrote, On 04/11/2009 10:49 PM:
> Dag Bakke wrote:
>> So the videobits appear to be built and added on to the kernel image
>> after the main chunk gets compressed. And the size of the video*.o
>> objects sums up to 87k.
>>
>> If my reasoning is too stupid for words, would you mind providing a
>> graphical illustration of my stupidity?  :-)
>>
> 
> It's not our job to do yours for you.

Subtle hinting does the job, too. :-)


> *.o files contain a LOT of metadata.  The "size" command tells you the
> real size.

Probably.
Hand-editing the video*.o-files out of the Makefile and dropping the
call to set_video in main.c gained me 4768 bytes. Definitely less than
87kB, but posibly worth the effort. To me, anyway.

Sorry about the noise, thank you for replying.

For the benefit of other readers working on small kernelimages, this URL
may prove helpful:
http://elinux.org/Kernel_Size_Tuning_Guide


Dag B

Re: video (VGA) object-files unconditionally built/included?

[H. Peter Anvin]

Dag Bakke wrote:
> 
> Probably.
> Hand-editing the video*.o-files out of the Makefile and dropping the
> call to set_video in main.c gained me 4768 bytes. Definitely less than
> 87kB, but posibly worth the effort. To me, anyway.
> 
> Sorry about the noise, thank you for replying.
> 
> For the benefit of other readers working on small kernelimages, this URL
> may prove helpful:
> http://elinux.org/Kernel_Size_Tuning_Guide
> 

For what it's worth, you're welcome to submit a patch which makes this a 
configuration option conditional on CONFIG_EMBEDDED.

	-hpa