lkml.org 
[lkml]   [1999]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernels > 1M
Riley Williams wrote:

> >> The reason for this is that the current kernel loader uses the
> >> value of a 16-bit unsigned int in the boot sector as the number
> >> of 16-byte paragraphs of kernel source to load, thus only
> >> supporting kernels of not more than 0xFFFF0 (1,048,560) bytes in
> >> size. Worse still, the value stored in this word is the lower 16
> >> bits of the calculated value, so if the kernel was, say,
> >> 0x107630 (1,078,832) bytes ( in size, the stored value would be
> >> 0x00763 paragraphs, or about 30k !!!
>
> > The kernel would work fine, *unless* you use the pathetically old
> > bootsect.S loader.
>
> True. Am I right in thinking that LILO still uses it?

I would be highly surprised if it was.

> > However, fixing that bug is a plus.
>
> Do you think there's any chance my patch as posted in the previous
> email will get in the kernel, will I need to repost it when the rest
> of the patch is finished and that bug is eradicated, or should I just
> forget about it as being something that's not worth doing?

Well, I have volunteered to Linus to make sure that some kind of
*complete* patch gets in, so presumably it will happen :) I, of course,
am completely happy not to do the work, so feel free to send me patches.


However, this is probably how you want to do the semantics for now:

If the size < 0xffff0
old_field := (size+15) >> 4
new_field := size
else
old_field := 0xffff
new_field := size

... and look at the new_field only if the old_field is 0xffff; that was
we maximize compatibility.

Not that I think it matters much.

-hpa


--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!

-
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.094 / U:1.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site