Hello all.
Well I wanted to ask theoretically where usually kernel should sit? I couldn't find answer to that question neither on google nor here.
And also if its possible can you comment on my own solution:
I tough leaving everything from 0x0 till 0xC0000000 for user space. 0xC0000000 to 0xC0100000 will be mapped to bios stuff (IVT, bootloader, frame buffer and etc), 0xC0100000 to some point that will be the kernel end lets say for now 0xC0200000, and starting from 0xC0200000 to around 0xCFFFF000 will be the kernel heap, and kernel stack will start from 0xCFFFFFFF and grow toward kernel heap. 0xD0000000, 0xE0000000, 0xF0000000 will be stuff like drivers, VBE, probably shared memory etc.
Thanks you.
Kernel place in memory?
Kernel place in memory?
TCP/IP: Connecting people...
Re: Kernel place in memory?
Hi,
you can allocate the first megaByte for your kernel and beyond for
kernel modules or user programs, so you can use this range to user
progs.
0x100000 - 0x??????
2nd MB - last MB in your memory
Note: you can use int 0x15 to calc. your total memory
CheerS
,
a.T.d
you can allocate the first megaByte for your kernel and beyond for
kernel modules or user programs, so you can use this range to user
progs.
0x100000 - 0x??????
2nd MB - last MB in your memory
Note: you can use int 0x15 to calc. your total memory
CheerS
,a.T.d
Distance doesn't make you any smaller,
but it does make you part of a larger picture.
but it does make you part of a larger picture.
Re: Kernel place in memory?
Hi,
The important thing here is that in your OS design, you can put anything anywhere in memory. So you need to tackle it from a simplicity point of view (simple memory areas -> less likely to lose track of where things are
).
As you correctly say, it is not unusual to have user space from 0x00000000-0xBFFFFFFF and kernel space thereafter. In this scheme, the 0xC0000000+ range will be present in the process space of every user application and you avoid memory space switches for system call handling.
Therefore, I would stick to the basic question: Is this item individual to a process? If so, place it below the 3GiB mark. If it is common to all processes, stick it above 3GiB. You may want to leave a 4GiB range somewhere in your kernel space to put the necessary paging structures (PD/PT's and so on). From looking at other OSes of people on this board, placing pageing structures from 0xFFC00000 - 0xFFFFFFFF seems fairly common. Again, there is no reason for this other than 'keeping it simple'.
You will not from the rule I outlined above that there are a few grey areas. Should a PCB be in the "individual user space" or should it be in the kernel heap? That's up to you. As for drivers, they can be in kernel space (and always will be in a monolithic kernel), but if you are writing a micro/nano/exokernel you may want them below 3GiB (I suppose they could be above 3GiB bu with user privileges? - I've never experimented with that).
HTH,
Adam
The important thing here is that in your OS design, you can put anything anywhere in memory. So you need to tackle it from a simplicity point of view (simple memory areas -> less likely to lose track of where things are
).As you correctly say, it is not unusual to have user space from 0x00000000-0xBFFFFFFF and kernel space thereafter. In this scheme, the 0xC0000000+ range will be present in the process space of every user application and you avoid memory space switches for system call handling.
Therefore, I would stick to the basic question: Is this item individual to a process? If so, place it below the 3GiB mark. If it is common to all processes, stick it above 3GiB. You may want to leave a 4GiB range somewhere in your kernel space to put the necessary paging structures (PD/PT's and so on). From looking at other OSes of people on this board, placing pageing structures from 0xFFC00000 - 0xFFFFFFFF seems fairly common. Again, there is no reason for this other than 'keeping it simple'.
You will not from the rule I outlined above that there are a few grey areas. Should a PCB be in the "individual user space" or should it be in the kernel heap? That's up to you. As for drivers, they can be in kernel space (and always will be in a monolithic kernel), but if you are writing a micro/nano/exokernel you may want them below 3GiB (I suppose they could be above 3GiB bu with user privileges? - I've never experimented with that).
HTH,
Adam
Re: Kernel place in memory?
Thanks a lot for explanation you two It really cleared something for me.
However I have just one more question: When one say: "First comes kernel, than heap, than stack, than drivers and etc)", he doesn't mean that drivers will be far from kernel and between heap and stack in real memory right? He means that virtually it will be there but physically they could come straight after the kernel, or between 2 user programs, Am I right? (I'm pretty sure I am, but just to be 100% sure).
Thanks again.
It really cleared something for me.However I have just one more question: When one say: "First comes kernel, than heap, than stack, than drivers and etc)", he doesn't mean that drivers will be far from kernel and between heap and stack in real memory right? He means that virtually it will be there but physically they could come straight after the kernel, or between 2 user programs, Am I right? (I'm pretty sure I am, but just to be 100% sure).
Thanks again.
TCP/IP: Connecting people...