>>> 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/