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.
bget and where code meets memory hardware
Moderator: Moderator Team
Re: bget and where code meets memory hardware
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...?
What does mean "to get memory" ? address it, allocate a chunk of...?
Re: bget and where code meets memory hardware
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.
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.
Re: bget and where code meets memory hardware
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.
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.
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.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.
Look at the kernel memory manager (which is in the process of rewriting) in ntoskrnl/mm subdirectory.
It does not start at 0, of course. The kernel gets the memory layout from the bootloader.[…] 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?
Hardware is not queried, the bootloader gets this information from BIOSHow is this max determined? Doesn't hardware need to be queried? Where is that?
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.The C code (at bget level) translates directly to assembly addresses in physical memory at this level?
***
Re: bget and where code meets memory hardware
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.
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.
This code is for ARM, I don't know anything about it.Is this the location you mention is determined via the bios?
If so, who actually calls LlbStartup ?
I talked about x86.
Look at Coreboot and SeaBIOS.Do you know of an open source bios project that would be a good example to coorelate with reactos's use of bios?
Who is online
Users browsing this forum: No registered users and 22 guests