Messages in this thread | | | Date | Sun, 8 Aug 1999 09:17:28 +0100 (GMT) | From | Riley Williams <> | Subject | Re: Kernels > 1M |
| |
Hi Peter.
>>> 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.
I wouldn't be at all surprised either way - I've seen too much code that makes hidden assumptions like that for anything to surprise me nowadays.
>>> 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.
OK. I'll be basing the rest of my work on the assumption that the patch I've already sent you applies before anything I send - ie, the next patch will be incremental to that one.
> 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 > endif
> ... and look at the new_field only if the old_field is 0xffff; > that was we maximize compatibility.
Noting the comments about INT 0x15 not being able to access beyond the 16M mark, and noting that the kernel gets loaded at the 1M mark, I was looking at the following semantics:
Q> kernel_size = (size + 15) >> 4 Q> if (kernel_size <= 0xffff) Q> syssize = kernel_size Q> else if (make_zImage) Q> die("Kernel too large for zImage loader") Q> else if (kernel_size <= 0xeffff) Q> syssize = 0xffff Q> else Q> die("Kernel too large for INT 15 loader") Q> endif
I would then tweak the code as compiled in the `make bzImage` case to use the kernel_size field rather than the syssize field, and the code in the `make zImage` case to use the lower two bytes thereof instead of the syssize field. That would leave the syssize field effectively unused...
Note that it stores the paragraph count in kernel_size as well as in the current syssize field, rather than the actual byte size as in your case. This is in my opinion preferable as the rest of the routine deals in paragraphs at the moment, so is likely to simplify the resulting code somewhat.
> Not that I think it matters much.
It probably doesn't, but we can at least kill the bugs therein.
One thing though: I have to admit that my assembly experience has primarily been with INTEL assembler, and in particular the A86 assembler's version thereof, so I'm not fully au-fait with the syntax used by as86. I noticed the .byte and .word macros for declaring variable storage in bootsect.S but is there one to declare a variable with 4 bytes of storage as well, or do I need to use the ".word 0,0" format?
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/
| |