Re: Kernel section info.

[Kurt Skauen]

OKUJI Yoshinori <address@hidden> writes:

 
> From: Kurt Skauen <address@hidden>
> Subject: Re: Kernel section info.
> Date: 01 Nov 2000 13:46:03 +0100
> 
> > But there is now way to know where to load a module before you know
> > what modules are needed and how big each module are.
> 
>   Ah, perhaps I'm talking about a somewhat different thing from
> you. Normally, you don't need to relocate any module physically,
> because MMU can translate virtual addresses into physical
> addresses and mostly that is sufficient. But it is sometimes necessary
> to locate a module at a certain _physical_ address, for example, when
> a module (such as L4-Linux) assumes that virtual memory is identical
> with physical memory. So I said that address embedding support would
> be useful.

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. Unless you built all the drivers
at different addresses, something that whould require that you knew
what drivers might be loaded upfront and that takes away most of the
reason (to me atleast) for using modules in the first place.

> > embedd them in the kernel. And it is not randomly in the current
> > version, it is back-to-back after the kernel image (I cheated and
> > looked at the source :). The problem is that you are not guaranteed
> > that they are loaded there according to the standard, and worse you
> > are not guaranteed that the module are loaded at increasing
> > addresses. I think that the module list given to the kernel should
> > always be sorted on the address of the modules since that simplyfies a
> > few things in the kernel.
> 
>   I'm not sure why that simplifies your kernel. Can you tell me how
> things will be complicated, if the order is undefined, in details?

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.

On the other hand, what are the arguments against this?

-- 
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