modularkernel-developer

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

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

Hi,

I have a few controling question to check my understanding.

Is PhysicalSuperMapStart always going
to be equal to PhysicalManagedInfoStart?

The PhysicalMapsStart is where we start to store
the individual map contents?

What is PhysicalLastFrame? I mean, I think I get how it is
computed, but I question whether it is always going to be valid.
For illustration, let's say Size will be (UINT32_MAX-Base+1).
I think this can occur when the machine has 4 gigabytes of ram.
Now, doing Base+Size will overflow, and the PhysicalLastFrame
will be zero. Which I do not think is the desired outcome.
What is it that I am not seeing here?

Is PhysicalLastFrame actually the index of the first unmanaged frame?
One that does not exist because it is beyond the actual available
physical memory?

About the line "PhysicalKernelEnd = PhysicalManagedInfoEnd;"
PhysicalKernelEnd is, so far, where the kernel machine code
and data structures end in the physical memory.
Correct?

Why are we doing address arithmetic in 4-byte quantities instead of 1-byte?
I mean, we need >>5 because we are using UINT*, instead of, let's say
char*, right?
Is it because of the bitmaps?

In _use_frames(), when  (Start+Count >= PhysicalLastFrame) is true,
shouldn't we panic, instead of just doing nothing?

Btw, I have added a few more comments to the source file.
It helps me a lot to quickly refresh my understanding of the source code.
I did read enough from this file for now, and I am going to read other
source files.

Tomas

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

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