[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kernel section info.

From: OKUJI Yoshinori
Subject: Re: Kernel section info.
Date: Fri, 03 Nov 2000 00:05:22 +0900

From: Kurt Skauen <address@hidden>
Subject: Re: Kernel section info.
Date: 02 Nov 2000 12:12:13 +0100

> relocation in the kernel anyway. And if you have support for
> relocating images in the kernel there is no need to place any (image)
> modules on a specific address.

  That's not always true, but I'd like to stop this discussion,
as this is not what we want to discuss.

> Finding the highes address is far from enough with the current
> specification. What if the bootloader decided to load the modules from
> the highest physical address and downward from there? Or if it placed
> the modules below 1MB with the top of the last module at 64KB? With
> the current specification you can't make *any* assumptions and then
> things get much more complex than what is neccesary. It is not a
> unresolvable problem by any means, but it is much more complex than it
> have to be.

  I see. IIRC, there was also a discussion about the location of
Multiboot information. In the discussion, someone said that a
Multiboot information structure should always be under 1MB. Maybe
should these be added into the spec?

* a Multiboot boot loader must load a module at a memory region which
is higher than a region for a kernel, unless the user (or the kernel)
requests the address of the module explicitly.

* The order of the loaded addresses of modules must be identical with
the order of modules in a Multiboot information structure passed to a
kernel, unless the user (or the kernel) requests any addresses of the
modules explicitly.

* A Multiboot information structure must be placed below 640KB, unless
the user (or the kernel) requests the address explicitly.

> complex. If the bootloader have to use extended memory it is
> sufficient to allocate memory top-down for the bootloader and
> bottom-up for the OS. I can't see that this should make a very big
> impact on the design of the bootloader.

  I disagree, but I'm now thinking that this change may be


reply via email to

[Prev in Thread] Current Thread [Next in Thread]