bget and where code meets memory hardware

All development related issues welcome

Moderator: Moderator Team

Post Reply
chupper
Posts: 3
Joined: Sun Feb 27, 2011 3:52 pm

bget and where code meets memory hardware

Post by chupper » Sun Feb 27, 2011 4:07 pm

Hi, I've been developing on windows a long time, and I'm getting more and more interested with the hardware in a system.
The first thing I wanted to learn about was memory.
I'm trying to understand how under a usermode app, under the kernel, under the memory manager, how does software actually get memory?
I'm completely clueless here.
I've drilled down via doxygen to bget and it looks like at the very base we just start at NULL.
I can accept that, but is it really that simple?
Does the Memory Manager really just start at 0 (NULL) and go up to some max?
I'm guessing this is the start (0 address)
bget.c 538 static void *(*acqfcn) _((bufsize size)) = NULL;
How is this max determined? Doesn't hardware need to be queried? Where is that?

Is it really this simple? The C code (at bget level) translates directly to assembly addresses in physical memory at this level?

An explanation would be greatly appreciated.

Thanks.

Mna.
Posts: 122
Joined: Thu Dec 02, 2010 3:13 pm

Re: bget and where code meets memory hardware

Post by Mna. » Sun Feb 27, 2011 4:27 pm

chupper, do you know assembler, do you know C? say, x86 asm, CPU architecture?

What does mean "to get memory" ? address it, allocate a chunk of...?

chupper
Posts: 3
Joined: Sun Feb 27, 2011 3:52 pm

Re: bget and where code meets memory hardware

Post by chupper » Sun Feb 27, 2011 4:58 pm

Yes, I know C. I know the basics of x86 assembly. I'm fairly proficient with windbg, traversing stack...
I've written some windows drivers (sys files) in C
But I'm not asking about allocating memory in a usermode process or even the kernel. I'm not talking about virutal memory or paging. These are concepts implemented by the OS. I'm trying to learn about the parts under that.
I'm asking about how the lowest level part of the OS actually gets memory from physical ram.

bugboy
Developer
Posts: 39
Joined: Thu May 22, 2008 9:23 pm

Re: bget and where code meets memory hardware

Post by bugboy » Mon Feb 28, 2011 3:34 am

I am also at a loss on your question.
But first if I may clarify a statement.
Virtual memory and paging are implemented by the OS and hardware, the MMU to be exact.
Back to the "get memory". Are you asking how the OS determines the amount of memory in the system. Other than that the OS kernel accesses memory directly.
Image

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto » Mon Feb 28, 2011 11:57 am

chupper wrote: I'm trying to learn about the parts under that.
I'm asking about how the lowest level part of the OS actually gets memory from physical ram.
ReactOS kernel maintains a list of free physical pages. Simply speaking, when a new page is required, it removes it from the list and adds a new entry to the page table.

Look at the kernel memory manager (which is in the process of rewriting) in ntoskrnl/mm subdirectory.
[…] it looks like at the very base we just start at NULL.
I can accept that, but is it really that simple?
Does the Memory Manager really just start at 0 (NULL) and go up to some max?
It does not start at 0, of course. The kernel gets the memory layout from the bootloader.
How is this max determined? Doesn't hardware need to be queried? Where is that?
Hardware is not queried, the bootloader gets this information from BIOS
The C code (at bget level) translates directly to assembly addresses in physical memory at this level?
The code you're referring to is in the FreeLoader, not in the OS kernel. The bootloader runs in an nonpaged mode (so yes, assembly addresses correspond to physical addresses) and switches to a paged mode before starting the ntoskrnl.

***

chupper
Posts: 3
Joined: Sun Feb 27, 2011 3:52 pm

Re: bget and where code meets memory hardware

Post by chupper » Mon Feb 28, 2011 6:28 pm

hto, those are the types of answers I'm looking for.
Thank you very much.

So, I've looked deeper given your guidance and it appears I'm at
http://doxygen.reactos.org/d7/d55/boot_ ... ource.html
...
LlbEnvParseArguments(Arguments);
...
Which will take you to
http://doxygen.reactos.org/d7/def/envir ... 6899b0f8a1
...
00045 case ATAG_MEM:

Is this the location you mention is determined via the bios?
If so, who actually calls LlbStartup ?
Is that the method called by the bios?
I don't see references to it anywhere.
Is the bios configured by something else to do this? Or is this a standard?
Do you know of an open source bios project that would be a good example to coorelate with reactos's use of bios?

Thanks.

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto » Tue Mar 01, 2011 7:48 am

Is this the location you mention is determined via the bios?
If so, who actually calls LlbStartup ?
This code is for ARM, I don't know anything about it.

I talked about x86.
Do you know of an open source bios project that would be a good example to coorelate with reactos's use of bios?
Look at Coreboot and SeaBIOS.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest