Very Computer

I'm not really clear on why the v2.1.x kernels support both zImage and
bzImage compressed formats.  

Given the size increase from 2.0.35 to v2.1.x, I understand why the bzImage
format exists.  Why, though, would the user (the builder of the kernel)
ever elect to use zImage when bzImage seems to do the job just as well
without the size constraint?  

Is there something about the bzImage format that is less efficient than
zImage?

If my v2.1.x kernel is sufficiently stripped-down that it can be loaded as
a zImage file, is there an advantage to creating the compressed kernel in
that format?

Thanks for the info.

Quote:Steve Snyder writes:
>I'm not really clear on why the v2.1.x kernels support both zImage and
>bzImage compressed formats.  

I think I heard somewhere that older versions of LILO only support
zImage.

Quote:>Given the size increase from 2.0.35 to v2.1.x, I understand why the bzImage
>format exists.

Huh?  I haven't seen 2.1 kernels being much larger than 2.0 kernels.
Sure, there are more devices supported in 2.1, so you can get a larger
kernel, but I don't see why normal kernels would be much larger.
Perhaps this is a matter of perspective, though when I've run 2.1
kernels (2.1.106 was the last one I tried, I think), I've still used
zImage.

Quote:>Why, though, would the user (the builder of the kernel)
>ever elect to use zImage when bzImage seems to do the job just as well
>without the size constraint?  

Habit.  That's why I use zImage.

--PC
--
The position and/or opinions in the above message are those of the Board of
Trustees of Dartmouth College.  Copyright (c) 1998.  All right reserved.  The
above positions are also held by Newt Gingrich, many foriegn world leaders, and
you who are reading them.  Preston bears no responsibility for the content.

I'm currently using v2.1.110 in a zImage format.  It works fine (hence my
original questions), but the kernel is definitely bigger than v2.0.34 even
with most device support removed from the config.

Older Lilo's and loadln's don't handle the bzImage format, so if you have such
a system, you need the old format.  I suspect is there mostly because nobody
has removed it by now though.

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA

Quote:> Older Lilo's and loadln's don't handle the bzImage format, so if you have such
> a system, you need the old format.  I suspect is there mostly because nobody
> has removed it by now though.

Oh, that's why both are there.
And how is everyone supposed to know whether they need the old format or
not?
I didn't even know that there was a problem with using the new format...

Quote:> > Older Lilo's and loadln's don't handle the bzImage format, so if you have such
> > a system, you need the old format.  I suspect is there mostly because nobody
> > has removed it by now though.

> Oh, that's why both are there.
> And how is everyone supposed to know whether they need the old format or
> not?
> I didn't even know that there was a problem with using the new format...

If you build the kernel with make zImage, and it fails the link step, it will
tell you to move things into modules or do make bzImage.

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA

Lots of portables have Severely Broken BIOS Syndrome, resulting in a
very bad thing happening to address line A20.  I don't know the nature
of the problem, but it goes away like other BIOS bugs as soon as the
kernel gets its wits about it.  The practical result is that such
machines cannot boot bzImage kernels but boot zImage kernels just
dandy.

The machine I'm typing this on happens to be one that can't boot
bzImage kernels.  It's of 1996 vintage, a mere P120 laptop from Dell,
but don't obsolete me just yet.  

Let's not agitate to get rid of zImage support, please.  It hurts none
and helps some.

Thanks,
Bill Gribble

sure, but why even offer the zImage at all?

--

I have followed this thread but have yet seen an answer to one of the
original questions: is there a performance penalty (memory usage, CPU)
in using bzImage instead of zImage ?

-----------------------------------------------------------------------

Laboratoire de Modelisation et Calcul  | Tel: +33 4 76 51 44 23
BP 53, 38041 Grenoble cedex (France)   | Fax: +33 4 76 63 12 63
-----------------------------------------------------------------------

In newsgroup: comp.os.linux.development.system

This has been cured in the latest 2.1.x kernels.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

I can report one experience which I recently had with the bzip format.
I recently downloaded a source archive.  I had the choice of fetching
the archive compressed by gzip or bzip.  The file was several
megabytes compressed and the bzip'd version was smaller by a
significant amount.  So to save time I fetched it.  But bunzip needed
so much memory on my humble 8 Mbyte machine (hence lots of swapping)
that it took a couple of hours to decompress the file!.

--
-----------------------------------------------------------------------------
Bill Metzenthen        | See http://www.suburbia.net/~billm/ for information


Melbourne, Australia   | the floating point environment on 80x86 Linux.
-----------------------------------------------------------------------------

despite the similarity in the naming, bzImage has nothing to do with bzip2.

--

| In newsgroup: comp.os.linux.development.system
| >

| > > sure, but why even offer the zImage at all?
| >
| > Lots of portables have Severely Broken BIOS Syndrome, resulting in a
| > very bad thing happening to address line A20.  I don't know the nature
| > of the problem, but it goes away like other BIOS bugs as soon as the
| > kernel gets its wits about it.  The practical result is that such
| > machines cannot boot bzImage kernels but boot zImage kernels just
| > dandy.
| >
|
| This has been cured in the latest 2.1.x kernels.

I think we are at cross purposes here... I can't see for the life of me
how any fix in a kernel could solve a problem which prevents loading of
the kernel.

I have a few old machines, too.

--

"If heros often had feet of clay, they were, at least, still heros. How
many other clay-footed humans could claim as much?"
        Michael Flynn, _Firestar_

|
| > Is there something about the bzImage format that is less efficient than
| > zImage?
| >
|
| I have followed this thread but have yet seen an answer to one of the
| original questions: is there a performance penalty (memory usage, CPU)
| in using bzImage instead of zImage ?

Sort of... some machines have a BIOS which won't boot a bzImage format
kernel. That's a performance problem, the kernel won't perform until
loaded ;-)

Once it's in memory format is irrelevant.

--

"If heros often had feet of clay, they were, at least, still heros. How
many other clay-footed humans could claim as much?"
        Michael Flynn, _Firestar_

In newsgroup: comp.os.linux.development.system

Quote:> |
> | I have followed this thread but have yet seen an answer to one of the
> | original questions: is there a performance penalty (memory usage, CPU)
> | in using bzImage instead of zImage ?

> Sort of... some machines have a BIOS which won't boot a bzImage format
> kernel. That's a performance problem, the kernel won't perform until
> loaded ;-)

> Once it's in memory format is irrelevant.

It's not a BIOS problem; it's an A20 problem.  The A20 changing logic
was broken for bzImage kernels until just recently.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables