lkml.org 
[lkml]   [1999]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bzImage patch ? for monolithic kernels
Hi Peter.

>>> Actually, I don't see why 16 MB would be a limit for bzImage
>>> either...

>> Memory says that the 16 MB limit is because the bzImage copying
>> code works in 286 protected mode, as that's the mode used by the
>> BIOS copying routines that it depends on, and 16 MB is the
>> hardware limit in that mode.

> Where do you see that?

There was a thread on this very subject on L-K a few months back, and
I believe it was Linus who pointed out that the BIOS call (Interrupt
15, function 87) that is used to effect the copy does so by switching
into 286 protected mode, and is thus subject to the 16M limitation
that mode has.

I've just had a look on the web, and the only description of that
function that I can locate is at the following URL:

Q> http://www.htl-steyr.ac.at/~_morg/pcinfo/hardware/
Q> interrupts/inte7do0.htm

The description there doesn't explicitly state any such limit
though...

>> If my patch works the way it looks like, then 64 Terabytes will
>> be the actual kernel size limit as far as storage is concerned,
>> so having a gzImage format that could work past that limit would
>> be feasible. Such would presumably be done via a two-stage
>> process, with the bzImage code copying the first 16 MB, and a
>> secondary routine then copying the rest of the kernel into place.

> This would just be a bug fix to bzImage, not a new format...

Not so much a bugfix as a tweak to get round the above hardware
limitation, if that limitation is indeed present. Also note that the
tweak wouldn't be needed unless the kernel was over 16M in size.

> ...(the boot loaders would be unaffected.)

Agreed - the secondary loader wouldn't jump into action until the
first 16M had been loaded, so the boot loaders would be unconcerned
with what happens at that stage anyway.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.072 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site