>>> 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?
> LILO reads the field setup_sects and it may write vid_mode. It
> doesn't use (or run) any of the code in bootsect.S. When loading
> images without implicitly known size, LILO requires the user to
> specify the size (i.e. image = /dev/foo range = 1-100).
> Considering that nothing but bootsect.S itself uses syssize, the
> most straightforward solution to the problem seems to be to
> change the unit of syssize from paragraphs to sectors, to
> increase the header version number in setup.S (not 100% clean,
> but the best approximation to a version number for bootsect.S we
> have), and to update the checks accordingly.
I'm actually working on a variant of this, that effectively replaces
the current 16-bit syssize field with a 32-bit one, but still
measuring the kernel size in paragraphs. The non-assembler code is
finished, and I'm tweaking the assembler code at the moment, and as
the code to be tweaked is all in setup.S, I don't need to worry about
squeezing it all into the boot sector.
Expect the finished version probably by the end of August, if the
feature freeze allows it to be included...
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/