Re: [Osso-develop] memory interface

[Marco P. <pec...@cl...>]

> From: Eismann <ei...@wa...>
> To: OSSO developer mailing list <oss...@li...>
> Subject: [Osso-develop] memory interface
>
> Hi all!
Hi!
Excuse me for the late reply,
I thought Ale replied to you, and he was thinking the same...

> Returning with the mem management topic.
Well well

> Any idea about the interface functions?
About the same...

> The physicall memory manager has functions like getpage and freepage...
yes.

> What about logical memory manager functions?
> And, will the kernel manage page directories and tables like now in message
> functions, create process functions and others?

Well, not really the kernel (in the sense that is not centralized).

My idea is a three level memory handler:

1) Page handler (serialized):
This level handles requests of pages, like

[Process: I need 30 pages]
<Kernel: Take them!>

Obiviously this is serialized, cause only one process a time (tricks
excluded) can use the data structures describing global memory. It handles
only pages, to make it as fast as possible.
It's interface is a kernel function, called internally.

2) Logical mapper:
It maps the pages obtained before where the process needs, and use it for
program starting, heap, messages and so on.
Obiviously at this level there are no process interaction, so things can
be done in parallel.
It's interface is made by getmesg(), or Mallosso(), or everything needs to
map memory onto process space.

These two levels are built in the kernel.

3) Malloc functions:
Done in the library, at user level. It makes the space obtained from the
logical level available to the process.
This is only the last ring of the chain, but obiviously it does not
concern kernel or os.

> I think it would be better (more clear) if the kernel touches this things
> the minimum possible.
Let's talk about it!
This was my idea, and I think it has some advantages:

- Kernel can do the things that is supposed to do (Starting process,
message passing) and heap handling without external interactions.
- It (may) be fast, cause the serialization points are reduced to the very
  minimum (and can be optimized in some way)
- Interactions between kernel and processes (that i really DONT KNOW HOW
  TO IMPLEMENT!!!) is needed only for swap.

I know that you like a different approach, by a process handling memory
request. Would you please explain me why and how you think so, the
advantages it has, and so on?
I like to have a global point of view and to think (and know) about
alternatives before making decisions and start coding, so your opinions
and ideas are very appreciated! Maybe we will implement your ideas...
(but you have to explain them :-)


Bye, Marco