Info on kernel location - 0xc0000000?? why???
Ahmed
I have a question about where kernel is built and loaded.
1. When a standard kernel is build, it is usually built starting at
address 0xC000000 (in the 0xC...... region). Why is the kernel built
at this location, and not at 0.
2. Why was the 0xC.... chosen, and not lets say 0x8....?
3. Why would someone choose a differnt region, lets say 0xC400....
or even at 0x8000. Would building it at 0x8000....make a difference,
what else would the user have to change in src code?
I know some of the above questions might seem very basic, or too
complex to answer in an message posting. But I have just started to
venture into this area, and any help would be highly appreciated.
Especially, links that specifically talk about this issue.
Thanks in adv,
Ahmed.
ctr2...@yahoo.com
> 1. When a standard kernel is build, it is usually built starting at
> address 0xC000000 (in the 0xC...... region). Why is the kernel built
> at this location, and not at 0.
Wild guess: Because if it were built at virtual address 0, that would
keep the system from detecting dereferenced NULL pointers?
Marginally less wild guess: Because the first megabyte of memory
usually has a bunch of semi-important structures (from the BIOS), and
the kernel shouldn't just overwrite them when they may be needed later
(like by X).
--
Eric McCoy <ctr2...@yahoo.com>
"I woke up this morning and realized what the game needed: pirates,
pimps, and gay furries." - Rich "Lowtax" Kyanka
Tauno Voipio
"Ahmed" <ahme...@hotmail.com> wrote in message
news:dacf857a.02030...@posting.google.com...
The kernel uses a common linear address range with the userland programs.
The common addressing simplifies the user/kernel data transfers in the
kernel.
The V86 (virtual 8086) addressing mode is limited by hardware to the first
megabyte of linear addresses, so there is an incentive to give the low
addresses to users. To keep the address ranges contiguous, the kernel is
pushed to the last gigabyte and the userland code can then use the three
lowest gigabytes of linear addresses.
If the hardware limitations are taken into account, the kernel could be
moved to a different address range. The move would affect the memory
management start-up code and little more.
Tauno Voipio
tauno voipio @ iki fi
Paul Black
> ahme...@hotmail.com (Ahmed) writes:
>
>
>>1. When a standard kernel is build, it is usually built starting at
>>address 0xC000000 (in the 0xC...... region). Why is the kernel built
>>at this location, and not at 0.
>>
>
> Wild guess: Because if it were built at virtual address 0, that would
> keep the system from detecting dereferenced NULL pointers?
A system doesn't have to have a NULL pointer address of 0. Only the C
null pointer constant has to be an integral constant of 0 - the compiler
can easily assign a different value into a pointer if it's being
assigned a constant 0.
> Marginally less wild guess: Because the first megabyte of memory
> usually has a bunch of semi-important structures (from the BIOS), and
> the kernel shouldn't just overwrite them when they may be needed later
> (like by X).
Not relevant. The kernel address is virtual, any information from the
BIOS would be at a physical address.
Paul
Ahmed
Still looking for decent answer to link to some pages that talk about
this issue. Thanks for the people how have responded. I have more
question:
1. When a user process is created, my understanding it gets mapped to
a virtual address space. Does it get
- The whole 4GB address space (considering a 32 bit system)
- OR just the first 3 GB (as linux takes the fourth one GB)
- OR just a portion of the whole 4 GB as deemed necessary.
In addition to your answer, some links to website that talk about this
issue, or to pages in the following books would be greatly
appreciated..:)
1. Linux Device Driver By Rubini
2. Understanding the Linux Kernel by Bovet.
Thanks in adv,
Ahmed.
ahme...@hotmail.com (Ahmed) wrote in message news:<dacf857a.02030...@posting.google.com>...
ctr2...@yahoo.com
> A system doesn't have to have a NULL pointer address of 0. Only the C
> null pointer constant has to be an integral constant of 0 - the
> compiler can easily assign a different value into a pointer if it's
> being assigned a constant 0.
Sure, but it'd break all existing programs. And it seems like a
perverse thing to do. Why bother remapping NULL pointers to some
other address when you can just use 0?
> > Marginally less wild guess: Because the first megabyte of memory
> > usually has a bunch of semi-important structures (from the BIOS), and
> > the kernel shouldn't just overwrite them when they may be needed later
> > (like by X).
> Not relevant. The kernel address is virtual, any information from the
> BIOS would be at a physical address.
Ah; I was under the impression that Linux used a more or less direct
mapping. If I'd given it any thought, it'd be obvious that it doesn't
(else Linux would require lots of RAM).
Tauno Voipio
>
> Still looking for decent answer to link to some pages that talk about
> this issue. Thanks for the people how have responded. I have more
> question:
>
> 1. When a user process is created, my understanding it gets mapped to
> a virtual address space. Does it get
> - The whole 4GB address space (considering a 32 bit system)
> - OR just the first 3 GB (as linux takes the fourth one GB)
> - OR just a portion of the whole 4 GB as deemed necessary.
The user's code gets the necessary linear (virtual) addresses it needs from
the low 3 Gbyte address space. The top gigabyte is accessible in kernel mode
only. The kernel uses different descriptor entries than the user code. The
user-assigned addresses are aliased with kernel addresses, so the kernel is
able to access the user's address space.
The shared libraries are also mapped to the user address space. They may
have different linear addresses for different processes, depending on how
many different shared libraries are used by the process. This is the reason
that shared code must be position-independent.
> In addition to your answer, some links to website that talk about this
> issue, or to pages in the following books would be greatly
> appreciated..:)
> 1. Linux Device Driver By Rubini
> 2. Understanding the Linux Kernel by Bovet.
The Bovet book is the reference here.
Chapter 2 handles memory addressing.
Chapter 6 handles memory management.
Chapter 7 handles process address space.
Chapter 14 handles disk caches.
Chapter 15 handles file access and mapping.
Chapter 16 handles paging and swapping.
Chapter 19 handles program execution.
Appendix A handles system startup.
Please note that it may be pretty difficult to understand some chapters if
you have left some of the preceeding chapters unread. Please read the whole
book.
The inclusion of disk file handling is no blunder here: memory management
and disk management are tightly interleaved in a virtual-memory system. You
should think the virtual memory consisting of the real RAM and disk page
file together.
The Rubini book should not be attempted before the Bovet book contents feel
understood.
A CPU programming reference like:
386DX Microprocessor Programmer's Reference Manual, Intel doc. 230985-002,
or an equivalent is also very useful here. (The original book is pretty old
now).
HTH
Pete Zaitcev
>
> A system doesn't have to have a NULL pointer address of 0. Only the C
> null pointer constant has to be an integral constant of 0 - the compiler
> can easily assign a different value into a pointer if it's being
> assigned a constant 0.
This is a very, very evil view, taken by many violent purists
inhabiting dark corners of comp.lang.c.
First, C++ specifies that NULL is 0, and making NULL anything
else breaks interface with C++.
Second, mass clearing of structures cannot make non-zero NULLs,
so you cannot just do memset(something, 0, sizeof(*something)),
which is very evil because it undermines forward source
compatibility. Evil purists assign members by hand, and when
new members get added, those are left unassigned.
There are other move dubious issues which I am not touching,
because purists managed to get better footing on them
(for instance, bss clearing making NULLs). But it all adds up.
If we talk about C in Linux newsgroup, NULL is zero, period.
Nonzero NULL belongs to comp.lang.c.
-- Pete