kernel presentation at ILUG on Sat.

[Charles Steinkuehler]

Hal Duston wrote:
> On Mon, 2003-05-05 at 15:53, JD Runyan wrote:
>> A quick checking of the kernel.org mailing list archives yields that I am both 
>> wrong and right.    bzImage can use almost any compression you have available 
>> to you, and if gzip is it it uses the maximum compression gzip offers. 
> 
> Can you provide a citation for this?  All my research indicates that the
> only compression the kernel supports is gzip.  Gzip is hard coded in
> arch/i386/boot/compress/Makefile.  The only architecture that I could
> find that appears to support bzip2 is the m68k architecture in
> arch/m68k/Makefile .

Sure you can use any compression you desire for the kernel.  All you 
have to do is write a stand-alone decompression utility (*NO* external 
library dependencies, so say goodbye to all those libc functions, but 
they're really just bloat-code anyway) capable of running without making 
any kernel calls (you *ARE* trying to decompress the kernel, after all), 
and doing all I/O by directly addressing the physical memory.   Since 
I'm sure everyone here is intimately familiar with doing raw memory 
access via C or their favorite high-level-language, including proper 
handling of the klunky but loved x86 page registers, I won't bore you 
with details.

Should be a piece of cake, especially since you can use assembly, C,  or 
your favorite programming language of choice, as long as you can create 
an object file with the proper link points.  There's even sample code 
provided in arch/i386/boot/compress, as well as the previously mentioned 
UPX code which can also be used as an example.

The trivial exercise of writing a 2:1 recursive compressor and reducing 
the kernel to a single byte (plus the extractor code, of course) is left 
for the reader.

Extra credit if your code doesn't crash my machine when I test it, or 
for using perl, python, or ruby, all of which would require slight 
modification to run in the available environment.

There will also be a 25% overall penalty for using forth, as that makes 
the problem too easy, followed by a 25% bonus for using my favorite 
low-level language of forth.  Note for the math impared: This results in 
a net penalty of 6.25% for forth implementations, but then you if you 
didn't know that, you wouldn't be using forth anyway.

I'll expect your submissions by e-mail no later than 3:00 PM tomorrow.

Note:  gzip and upx based submissions will be disqualified, for obvious 
reasons.

-- 
Charles Steinkuehler
charles at steinkuehler.net