[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
acceptable.
Okuji
- Re: Kernel section info., OKUJI Yoshinori, 2000/11/01
- Re: Kernel section info., Kurt Skauen, 2000/11/01
- Re: Kernel section info., OKUJI Yoshinori, 2000/11/01
- Re: Kernel section info., Kurt Skauen, 2000/11/01
- Re: Kernel section info., OKUJI Yoshinori, 2000/11/01
- Re: Kernel section info., Kurt Skauen, 2000/11/01
- Message not available
- Message not available
- Re: Kernel section info., Kurt Skauen, 2000/11/02
- Re: Kernel section info., OKUJI Yoshinori, 2000/11/02
- Re: Kernel section info., Kurt Skauen, 2000/11/02
- Re: Kernel section info.,
OKUJI Yoshinori <=