Re: Kernel section info.

[Kurt Skauen]

OKUJI Yoshinori <address@hidden> writes:

> 
> From: Kurt Skauen <address@hidden>
> Subject: Re: Kernel section info.
> Date: 02 Nov 2000 10:56:28 +0100
> 
> > But even if you can use the MMU you can't put two device drivers on
> > the same virtual address (in a non-microkernel that is) so you will
> > have to relocate the drivers anyway.
> 
>   That's not relevant to my argument, since that doesn't need physical
> relocations anyway. I'm not talking about relocations on virtual
> memory.

With "relocate" I was not talking about the act of moving the module
in memory (or mapping the pages to another virtual address), but the
act of relocating all pointers inside the image. If the virtual
address the module was meant to be placed on is used by another module
already you will have to put the second module on another virtual
address and if you put it on another address you must relocate all
pointers in the executable image so you need support for pointer
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.

> > The AtheOS kernel treat memory below 1M differently and it is hard to
> > tag memory as used at an early stage. This is ofcourse very AtheOS
> > specific, but there is a few other problems aswell if there is no
> > rules at all for where the modules might be located, and when they are
> > not sorted. In AtheOS I need to setup a few tables that is variable
> > sized before the memory management are initialized. If the modules
> > where stacked together and sorted I could just put it after the last
> > module in the list. Now I need a much more complex allocation algorithm
> > for "pre-memorymanagment" allocations, and I can imagine that this
> > problem will arise in other kernels aswell.
> 
>   I must admit that things would be simpler if the order is
> guaranteed, but how difficult is it to get the highest address of
> modules? Can't that be implemented in only a few lines?

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.

> > On the other hand, what are the arguments against this?
> 
>   That affects the design of a Multiboot boot loader. For now, GRUB
> has a lot of deficiency, because GRUB cannot use memory freely. But,
> in the future, GRUB will use extended memory for its own purpose. If
> we add more restrictions on memory usage into the specification, it
> would be harder to enhance GRUB. Of course, only GRUB isn't a
> Multiboot boot loader, so you need to take it into account that there
> may be other boot loaders which would be affected.
> 
>   IMO, any specification should be established, based on the balance
> (or trade-off) among all software related to the specification. It
> would result badly, if you consider only the convenience for OS
> developers. So if a thing is easily implemented in an OS, it should be
> implemented in the OS. I don't want to change the specification
> unnecessarily.

That's my point exactly (like stated in another posting). I believe
implementing this in the bootloader is very simple (it is in fact the
way GRUB works today) while doing it in the kernel can be very
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.

-- 
Kurt Skauen. ( http://www.atheos.cx/ )

"There are two kinds of people, those who do the work and those who take
credit. Try to be in the first group, there is less competition there." __
Indira Gandhi