Re: [Modularkernel-developer] PhysicalMapsStart and other, in physical_memory.c

[Daniel O. <mus...@go...>]

Hi :)

Sorry for not being there doing something (visible) for such a long time.
In fact, i had a complete reimplementation (but of course with nearly 
the same design) of the physical memory management, that is actually 
followed by a redesign of the virtual memory management and a small 
design change concerning multitasking.

So there are a lot of changes that i didn't pushed yet, i hope i can put 
it online tomorrow or the day after tomorrow.
I will try to take as much of your comments as possible and add my own 
to make the code easier to understand this time.
The last code first wasn't coded with the idea of other people working 
on it, too ;)
Its sometimes just hard to code and comment at the same time, but i hope 
i won't forget commenting anymore ^^


About the physical memory management:

I removed the thing about the "base", from which on we were managing the 
memory. Now everything is managed. There is also a change in "using" the 
physical memory management. The lower level functions now return a value 
indicating whether they could do the job they were told to and the real 
"return" value is handled using pointer parameters.

Just a note about your concern about the base+size overflow. This is now 
not possible anymore, but i think it wasn't before. That's because the 
value "size" is somehow always less than the real memory size.
Using 8 MB i got size values which told me that i had about 7.5 MB of 
main memory.
So this size value is somehow a minimum of available memory.

The thing about PhysicalLastFrame : I implemented this because i thought 
that we would need some sort of possibility to check, whether the frame 
we are allocating or freeing is even "there".
I am not completely sure whether this is really necessary, as error 
checks could be made on a higher level. What do you think about that?

About PhysicalKernelEnd: Yes, that's right :)

Next your question about the 4 byte arithmetic: I am using 4 byte 
arithmetic because it is much faster than 1 byte arithmetic.
A 32 bit processor can access 4 byte at once, so only checking 1 byte at 
once would leave 3/4 of the "power" unused.
There is of course a "overhead" of doing the right arithmetic. But these 
are only bit shifts, which aren't very expensive :)
I don't know much about embedded systems and whether they support 4 byte 
rates, so i don't know if this could be ported to such systems.

About the problem in _use_frames() : Yes, you are right, but we won't 
actually use this function anymore.
This problem is also connected to the question where we should do the 
error checking.

Daniel :)