Page 1 of 1
placement allocation
Posted: Tue Apr 12, 2011 7:07 am
by mariuszp
I looked at JamesM's code for the placement allocator and noticed that when we want the physical address, then before actually increasing the placement address, JamesM used the following code:
Code: Select all
if (phys)
{
*phys = placement_address;
};
I just wondered,
how does this code make sure the address is physical? It's more like storing a copy of placement_address before it is updated to allocate memory. I just don't get it. How does this make the address physical
EDIT: So, basically, the *phys will become the return value of the function. It doesn't make sense!!!
Re: placement allocation
Posted: Tue Apr 12, 2011 7:27 am
by Solar
Since I never did read JamesM's code, and you didn't provide a link, I googled for it and came up with
this page. I am assuming this is what you are talking about.
Right before the code is presented, I find this (emphasis mine):
JamesM wrote:Now, unfortunately, we have one more requirement, and I can't really explain to you why it is required until later in the tutorials. It has to do with when we clone a page directory (when fork()ing processes). At this point, paging will be fully enabled, and kmalloc will return a virtual address. But, we also (bear with me, you'll be glad we did later) need to get the physical address of the memory allocated. Take it on faith for now - it's not much code anyway.
Did you actually continue on faith until the "later" he refers to, and
still don't understand it - or did you lack faith?
Taking code out of the midst of some tutorial without actually working through the tutorial can be quite confusing sometimes, because you miss out on previous and later explanations on why the author did things the way he did. TIMTOWTDI - There is (always) more than one way to do it.
Re: placement allocation
Posted: Tue Apr 12, 2011 7:34 am
by mariuszp
Solar wrote:Since I never did read JamesM's code, and you didn't provide a link, I googled for it and came up with
this page. I am assuming this is what you are talking about.
Right before the code is presented, I find this (emphasis mine):
JamesM wrote:Now, unfortunately, we have one more requirement, and I can't really explain to you why it is required until later in the tutorials. It has to do with when we clone a page directory (when fork()ing processes). At this point, paging will be fully enabled, and kmalloc will return a virtual address. But, we also (bear with me, you'll be glad we did later) need to get the physical address of the memory allocated. Take it on faith for now - it's not much code anyway.
Did you actually continue on faith until the "later" he refers to, and
still don't understand it - or did you lack faith?
Taking code out of the midst of some tutorial without actually working through the tutorial can be quite confusing sometimes, because you miss out on previous and later explanations on why the author did things the way he did. TIMTOWTDI - There is (always) more than one way to do it.
I read the whole tutorial before, and there was no explanation of
how it works. I do understnd
why we need physical addresses, but not
how they are obtained. Storing the return value in a pointer does not make it physical. And since paging is not enabled, and the GDT 'base' for every gate is at 0, the address returned is physical either way.
Re: placement allocation
Posted: Tue Apr 12, 2011 7:35 am
by gravaera
Faith is the substance of code hoped for, the evidence of concepts not seen; Have faith my brother, and you will pull through. When you're done having faith in unsuitable material, you can begin reading up on proper memory management from these links:
http://en.wikipedia.org/wiki/Memory_management
http://tldp.org/LDP/tlk/mm/memory.html
And believe...
Re: placement allocation
Posted: Tue Apr 12, 2011 9:15 am
by Solar
mariuszp wrote:I read the whole tutorial before, and there was no explanation of how it works.
I freely admit I've never read it before, and that I'm just using my cross-reading abilities to point out likely points of explanation.
The "take it on faith" part of the tutorial seems to reference
Chapter 9.2 Cloning an address space. Is there anything in
that chapter that sheds some light on your problem?
(Sorry,
awfully tight on time myself, so I can't really read / think this through.)
Re: placement allocation
Posted: Tue Apr 12, 2011 11:55 am
by JamesM
I just wondered, how does this code make sure the address is physical?
Because placement_address is only used in the pre-paging stages, it has to be physical by definition.
Re: placement allocation
Posted: Tue Apr 12, 2011 12:47 pm
by mariuszp
JamesM wrote:I just wondered, how does this code make sure the address is physical?
Because placement_address is only used in the pre-paging stages, it has to be physical by definition.
But if I do:
Code: Select all
// placement allocation still active!
u32int phys;
u32int out;
out = kmalloc_p(1234, &phys);
Then out == phys, so why not just:
Code: Select all
u32int phys;
phys = kmalloc_p(1234);
That's my question.
Re: placement allocation
Posted: Tue Apr 12, 2011 2:22 pm
by NickJohnson
@berkus: yes, it is. The physical address parameter is redundant now, but becomes useful later.
However, I prefer to use a different method. Instead of making kmalloc give physical addresses for the virtual addresses it allocates, I find it easier to have a separate function (page_phys() in my kernel) that gives the physical address of a given virtual address. It simply uses the page tables to do this, in the same way that the MMU itself does. This lets you get the physical address of any pointer at any time, instead of only at allocation.
Re: placement allocation
Posted: Tue Apr 12, 2011 4:25 pm
by NickJohnson
I know: it was just a suggestion.
Re: placement allocation
Posted: Wed Apr 13, 2011 2:44 am
by JamesM
berkus wrote:It's a tutorial code we're speaking about.
And **** tutorial code at that.
</author>