Messages in this thread | | | Date | Sat, 07 Aug 1999 16:28:26 -0700 | From | "H. Peter Anvin" <> | Subject | Re: 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/
| |