[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: Thu, 02 Nov 2000 19:44:55 +0900

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

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

> 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


reply via email to

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