>> 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.
> It would be very bad to boot 99% of a kernel, since it may well appear
> to work.
With the scheme I proposed, that can never happen.
> If there is any chance of that, this would be better:
> p = (size+15) >> 4
> if size < 0xffff0
> old_field = p
> new_field = 0
> else
> old_field = p >> 16
> new_field = p & 0xffff
> Then at boot:
> p = old_field
> if p < MIN_KERN_SIZE
> size = ( (p<<16) | new_field ) <<4
> else
> size = p << 4
> If you don't like that hack (saving a couple bytes), how about a
> low magic value? Anything too small for a kernel would be fine.
Albert, you're solving a non-problem with that argument, so can I
clarify the situation:
1. My understanding is that all of the boot loaders other than
the one built into the kernel itself can already load kernels
larger than 1M. So far, nobody has contradicted this claim,
but if there is a boot loader that can't, please say so.
2. Since the current kernel provides NO indication of the size
of any kernel larger than 1M, boot loaders capable of loading
suchlike kernels can't be getting the kernel size from any
field within the kernel. This implies that there is no way
that any patch I provide can break any such loader.
The consequence of the above two facts is that the ONLY way that an
incomplete kernel could be loaded is by trying to use the inbuilt boot
loader with a kernel larger than 1M in size, in which case the said
scenario is GUARANTEED to happen.
There IS a possible problem that we need to guard against, which is
the use of old utilities that can tweak the kernel parameter fields.
To the best of my knowledge, utilities such as rdev do not touch the
kernel size field, BUT I CAN NOT GUARANTEE THAT.
It is because of THIS problem that I have chosen the route I have for
upgrading the inbuilt boot loader, and the basic consequence of that
possible problem is that we can NOT safely make use of the old size
field at all.
As a result, the design for the revised boot loader is as follows:
1. If we are doing `make zImage` then use the current zImage
boot loader, with a kernel size limit of 508k as currently.
This is unchanged, and I see no need to change it. It will
still use the current kernel size field since that is all
that is needed in this case.
2. If we are doing `make bzImage` then use the revised bzImage
boot loader, which can happily handle kernels up to 15M in
size. THIS is where my efforts are concentrated. It will
make NO USE WHATSOEVER of the current kernel size field, but
will instead refer exclusively to the new kernel size field.
As a result, the value stored in the current kernel size
field is completely irrelevant.
For reference, I believe that I have this all sorted out, but am
testing it before release to ensure that what I produce will actually
work. I have to admit that the need to generate a kernel between 1.1M
and 1.3M in size is proving difficult, but I expect this to be sorted
out later this week.
Comments?
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/