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

[Tomas K. <tom...@gm...>]

Hi,

On Wed, Apr 21, 2010 at 4:10 PM, Daniel Oertwig
<mus...@go...> wrote:
> Hi :)
>
> Sorry for not being there doing something (visible) for such a long time.

It's ok with me.

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

How are we going to try out the (user-space?) multitasking?
AFAIK, we don't have a way to start user-space processes yet.

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

Thanks.

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

I think you should comment as you see fit.
I am glad that my comments/macros do not disturb the original coder :)

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

This "return" value is something else than just an integer (like long)?
If it's only an integer, I think I would prefer to return the error code,
instead of writing it somewhere into memory. As you save space on stack frame
for passing the pointer.

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

I see. Do you think we could add a check right before we start using
these two values (base, size)? This would serve both as documentation
that "we need this to be true" and as precondition check "if it is not,
we do not continue further".

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

I would leave this check in there, because in theory (as mentioned above,
the "size" argument is always less than the real memory size),
such frame can be constructed.

> as error
> checks could be made on a higher level. What do you think about that?

I think we can use error/invariant/{pre|post}condition checks
during the development. It speeds up the whole development process
a lot (at least from my experience). We can also make
these checks conditional, so that we can have a #define which
will decide whether the checks get compiled in or not.

Where to place these checks is a different question.
And I do not a direct answer for this. We will need checks
on all levels of the source code hierarchy.

I place checks as I see fit.

Example 1: If it is something that I only
setup at the beginning of the process and do not change
later and seemingly, there is no memory being overwritten
near where the value is stored, then I check it only once
after it is set. Also, I do not check everything. I check stuff
that is (sort of very) important, and in which it is likely that I
will do mistake,
and which is potentially hard to debug (find out the cause of the
runtime error).

Example 2: If it is something that can be changed and place A,
and then subsequently used in places B, C, D, then I place checks
at each place (B, C, D).

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

I get it now. About the embedded world. I do not know either.
I think the important question here is how much memory the embedded
system has to have at least, so that we decide that we would like to support it.
With 16-bit, or 24-bit systems, you do not get much memory.
And to me it seems that the embedded world is related to audio/video
processing, where I would expect the need for a lot of memory.

Tomas